How ISO 27001 A.5.33 Protects Fairness Evidence in Gaming & Trading Records

Why fairness evidence is your real product

Fairness evidence is the body of records that lets you prove every outcome, price and settlement was generated and handled as promised. It turns vague assurances about “fair games” or “robust markets” into something a regulator, court or dispute body can actually test. When those records are complete, consistent and robust, fairness is a fact you can show, not an argument you have to win. In gambling and trading, that evidential spine matters as much as the games and markets themselves, because regulators, partners and customers ultimately judge you on what your data can prove.

Fairness lives or dies in the quality of the records you keep.

When a player complains, a regulator investigates or an AML review lands on your desk, the only storey that counts is the one told by your records. Random number generator (RNG) logs, game mathematics and trading records are the raw artefacts that show whether each outcome was generated, priced and settled as intended. If those artefacts are incomplete, inconsistent or easy to challenge, fairness turns from a fact into an argument that you are less likely to win.

Most gambling and financial regulators expect you to be able to reconstruct historic rounds and markets from tamper‑resistant records. If you cannot do that reliably, it becomes much harder to prove that your platform is fair, well governed and worthy of long‑term trust.

This information is general in nature and does not constitute legal or regulatory advice. You should always take advice from suitably qualified professionals for your specific jurisdictions and licences.

What fairness evidence covers

Fairness evidence covers every record you need to rebuild a disputed round or market and explain it in plain language to a non‑technical audience. It links the randomness that drove the outcome, the models that shaped behaviour and the bets or trades that exposed and settled risk, forming a chain of technical and business records that lets you reconstruct any round or market, explain it clearly and defend it with confidence to regulators, auditors and dispute bodies.

In practice, three record families dominate that chain:

RNG logs: – seeding, configuration, version and each call that contributes to an outcome.
Game maths: – models, return‑to‑player (RTP) calculations, pay tables, symbol strips, volatility profiles and test reports.
Trading records: – bets or trades, odds or prices, exposure, hedging activity, outcomes and settlements.

Individually these can look like technical exhaust. Together, they form an evidential spine: which RNG instance and seed were used, which maths version was live, which odds were offered and accepted, and how the payout or settlement was calculated. That spine is what lets you answer hard questions years after the event.

How broken records damage your licence

Broken fairness evidence makes simple questions hard to answer and serious allegations hard to rebut. When records are incomplete, inconsistent or fragile, straightforward queries quickly become existential problems for your business. If you cannot show what should have happened and what actually did happen, allegations about rigged games or unfair markets are much harder to rebut, especially when you are under time pressure and public scrutiny.

When the chain between RNG logs, game maths and trading records is broken you face three overlapping risks:

Regulatory risk: – you cannot prove compliance with licence conditions and technical standards.
Dispute risk: – you struggle to defend decisions with alternative dispute resolution bodies or courts.
Reputational risk: – players and partners are more likely to believe rigged narratives when you cannot show clear evidence.

Operationally, this shows up as long investigations, conflicting explanations and ad‑hoc data pulls that still fail to answer basic questions. Strategically, a single high‑profile incident where you cannot evidence fairness can be enough to trigger licence reviews, additional conditions or the loss of key B2B relationships.

Treating these artefacts as fairness evidence rather than background data turns ISO 27001 A.5.33 from a box to tick into a way to protect your licence and brand. The same discipline also underpins meaningful responsible‑gambling and market‑integrity analytics. To do that well, you need to understand exactly what A.5.33 expects from gaming and trading platforms.

Book a demo

What ISO 27001 A.5.33 really asks of gaming platforms

ISO 27001 A.5.33 asks you to treat important information as records, then protect those records from loss, destruction, falsification, unauthorised access and unauthorised release for as long as you legitimately need them. It is short on words but long on implications for gambling and trading platforms. In plain language, it expects you to decide what information counts as a record, then protect those records across their lifecycle. For fairness evidence, that means treating RNG logs, game maths and trading data as first‑class records, not disposable exhaust.

A.5.33 applies across the full lifecycle of records, not just storage. You are expected to define what should be captured, how it is handled, how long it is retained and how it is ultimately destroyed or anonymised in line with your legal, regulatory, contractual and business obligations. Regulators and auditors will look for evidence that your records regime is deliberate, documented and enforced in day‑to‑day operation.

How A.5.33 defines and scopes “records”

For the purposes of ISO 27001, a record is information that documents an activity or event and may later be needed as evidence. A.5.33 expects you to decide which information falls into that category, document those decisions and then protect the chosen records accordingly. For fairness, that means being explicit about which logs, models and transaction data must stand up months or years later.

For RNG logs, game maths and trading records, this means you should make clear decisions about:

What exactly counts as a record (for example, which RNG events and which game configuration parameters).
How those records are created and captured in your systems.
How they are stored, protected and made retrievable on demand.
How long they are kept and in what form.
How and when they are securely disposed of or transformed.

It is important to distinguish records from documents. Policies, procedures and runbooks are documents that guide behaviour. RNG logs, maths configurations and trading data are records that evidence what actually happened. A.5.33 is mainly concerned with that evidential layer.

Lifecycle expectations for gaming and trading data

A.5.33 expects your records management arrangements to span the entire lifecycle of evidence‑grade data, not just the point where it lands in storage. You need to understand where fairness records enter your systems, how they move, how long they remain needed and how they are finally removed or anonymised. Without that lifecycle view, protections tend to be patchy or rely on individual engineers’ habits. For gaming and trading environments, that lifecycle typically includes:

Creation and capture: – where and how records enter your systems.
Storage and handling: – how they are stored, replicated, protected and accessed.
Transport and sharing: – how they move between services, partners, regions or data centres.
Retention and archival: – how long they are kept in different forms and tiers.
Disposal or destruction: – how they are securely removed or anonymised at end of life.

A.5.33 also expects you to tie these activities to other parts of your information security management system (ISMS). That includes:

Legal and regulatory requirements (A.5.31) that drive retention and confidentiality.
Information classification rules (A.5.12) that distinguish high‑integrity, high‑availability records.
Logging and monitoring controls (such as A.8.15) that support completeness and integrity.

Clause 9.2 on internal audit and Clause 9.3 on management review also link closely to A.5.33, because they provide the governance mechanisms that test whether your records design and operation are still fit for purpose. Having a SIEM, backups and an archive is not enough on its own; the standard expects a clear, justified design that reflects the risk of losing or weakening critical records like RNG logs and trade histories.

Once you know what A.5.33 means in practical terms, the next step is to map those requirements onto the real data flows in your RNG, game and trading systems.

ISMS.online gives you an 81% Headstart from the moment you log on

ISO 27001 made easy

We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.

Get started

Mapping A.5.33 to RNG logs, game maths and trading flows

You cannot protect fairness evidence effectively until you have mapped where it is created, where it moves and where it rests. Modern platforms spread RNG operations, game logic and trading across many services, regions and partners, so a simple “database plus logs” picture is rarely accurate. A.5.33 becomes much easier to fulfil once those flows are visible and owned.

If you take the time to trace end‑to‑end data flows, it becomes much easier to decide where records must be captured, how they should be protected and how you will demonstrate compliance with A.5.33 when challenged. That mapping work also exposes gaps where fairness evidence currently relies on informal processes, personal spreadsheets or undocumented integrations.

Tracing end‑to‑end fairness flows

End‑to‑end fairness flows are the paths data follows from initial player action or market creation through RNG, game engines, trading logic and settlement. By tracing those paths, you can identify which events and data items must be preserved as evidence and which can remain short‑lived telemetry. That clarity stops you over‑collecting noise while missing the records regulators will actually ask for, especially on the fairness‑critical RNG, game and trading flows that span multiple systems and, sometimes, multiple organisations and jurisdictions.

For each of these flows, you should identify:

RNG paths: – where RNGs run (hardware modules, virtualised services), how seeds are generated and stored, what is logged per call and where those logs land.
Game flows: – how a game round is triggered, which maths model and pay table it references, how intermediate states (spins, bonus triggers, jackpots) are represented and how final outcomes are recorded.
Trading flows: – how odds or prices are set, how bets or trades are accepted, matched and settled, how exposure is tracked and how adjustments or voids are applied.

For each flow, decide which events and data items you must be able to reconstruct later to satisfy regulators, auditors and dispute handlers. That usually includes the RNG instance and configuration, the game maths or trading model in force, the bet or trade parameters and timestamps, the sequence of states or decisions and the payout or settlement calculation.

Distinguishing telemetry from evidence‑grade records

Clear distinctions between operational telemetry and evidence‑grade records help you spend protection effort where it really matters. Short‑lived telemetry is invaluable for support and debugging, but it rarely needs long retention or high‑assurance storage. Evidence‑grade records, by contrast, must survive for years and still be trustworthy when you surface them in front of a regulator or dispute body. To achieve that, you need to separate quick‑rotation telemetry from long‑lived fairness records.

Not every log line or metric needs A.5.33 treatment. Some telemetry exists purely to help engineers debug issues and can have a short life. A simple way to clarify the difference is to compare operational telemetry and evidence‑grade records for key data types:

You can think about it this way:

Record type	Operational telemetry example	Evidence‑grade record example
RNG activity	Debug logs of RNG service health checks	Immutable log of each RNG call with seed and ID
Game behaviour	Application logs of button clicks and views	Versioned maths pack linked to each round outcome
Trading	Real‑time exposure dashboards	Trade book with timestamps, prices and settlements

Operational telemetry can often be rotated quickly. Evidence‑grade records need stronger guarantees for integrity, availability and retrievability over years. A.5.33 expects you to route the latter into storage and governance regimes that reflect that importance.

You should also pay particular attention to where flows cross organisational and jurisdictional boundaries:

B2B game studios and content aggregators.
Cloud regions and data centres.
Liquidity providers and external markets.

Each boundary is a potential weak point in the evidential chain. Contracts, integration patterns and technical controls should be shaped so that you can still retrieve complete, trustworthy records years later, even if a partner changes systems or a cloud region is decommissioned.

Once those flows are mapped, you have the raw material for a more deliberate records design, which is where a coherent records assurance stack becomes invaluable.

The records assurance stack framework

Records protection decisions are much easier to make and explain when everyone shares the same mental model. A records assurance stack gives Compliance, Security, Engineering and Product a common way to talk about what A.5.33 requires and who owns what, so design, operation and evidence stay aligned over time. Instead of jumping straight from “the law says keep records” to “we have some logs in S3”, you can walk regulators and auditors through layers that connect legal duties to concrete technical controls and day‑to‑day practice.

At its simplest, that stack has five layers that sit between law and storage, each with different responsibilities and owners. When you describe A.5.33 controls in these terms, it is easier for auditors and regulators to see that you have considered both design and daily operation.

The five layers of a records assurance stack

The five layers of a records assurance stack run from business and legal requirements down to the evidence you show during audits and investigations. Each layer turns abstract duties into more concrete decisions about data, technology and process. Together they form a traceable chain from “why we keep this” to “how we prove it works in practice”.

A records assurance stack for RNG logs, game maths and trading records usually includes:

Business and legal requirements
This layer captures the laws, regulations, licence conditions, contracts and internal policies that apply to each type of record, including what they say about retention, confidentiality, integrity and accessibility.
Data models and classification
Here you define how records are structured (events, tables, files, configurations) and how they are classified for confidentiality, integrity and availability. Those classifications drive handling rules such as encryption, access restrictions and resilience levels.
Technical storage and immutability
This layer describes where records are stored (databases, object storage, write‑once volumes, cold archives) and what protects them from tampering or loss, such as redundancy, integrity checks, immutability features and environmental controls.
Access control and monitoring
Here you define who can read, create, modify or delete records, how those actions are logged and reviewed and how unusual patterns (bulk exports, deletions, configuration changes) are detected and investigated.
Audit and evidence packaging
This final layer focuses on how records, policies and design artefacts are assembled into evidence that auditors, regulators and dispute bodies can understand, proving both design (controls exist) and operation (controls are used and effective).

Visual: five‑layer records assurance stack from law and business requirements down to audit‑ready evidence.

When A.5.33 issues surface during an audit, the root cause is often higher in the stack than engineers expect: unclear legal mapping, unclassified datasets or models held entirely in spreadsheets or notebooks outside any formal governance.

Who owns each layer in your organisation

Each layer naturally belongs to different teams, and recognising that helps you close gaps more quickly and avoid finger‑pointing when something goes wrong. Clear ownership also means you can show auditors that responsibilities for fairness evidence are defined and exercised in practice, not just written down. It also helps ensure improvements to logging or storage do not stall because nobody feels accountable for the full chain.

Compliance, Legal and the MLRO: usually own business and legal requirements.
Information Security and Data teams: often own data models and classifications.
Platform and Infrastructure engineering: typically own storage, resilience and immutability.
Security operations and Internal Audit: handle monitoring, testing and challenge.
The ISMS manager or ISMS steering group: coordinates how everything is presented externally.

An ISMS platform such as ISMS.online can mirror this structure by linking legal and regulatory registers to asset inventories, associating each record type with technical controls and tying those to evidence artefacts and internal audit findings. That turns records protection from a scattering of personal spreadsheets and shared drives into a visible, managed part of your overall security posture.

When teams see where they fit in the stack and how their actions contribute to fairness evidence, it is easier to justify investments in better logging, storage and governance and to sustain improvements beyond a single audit cycle. The next design challenge is to make individual records, such as RNG logs and game maths, tamper‑resistant in day‑to‑day operation.

Embed, expand and scale your compliance, without the mess. IO gives you the resilience and confidence to grow securely.

Book your demo

Designing tamper‑resistant RNG and game maths records

Tamper‑resistant fairness records give you confidence that what you show regulators and dispute bodies is what actually happened, not what someone would have liked to happen. RNG logs and game maths artefacts are attractive targets for anyone seeking to manipulate outcomes, hide issues or gain an unfair edge, so A.5.33 expects you to protect them from deliberate tampering as well as accidental loss. You do that by combining storage choices, cryptography and disciplined access control so that unauthorised changes are highly unlikely and easy to detect.

A sensible pattern is to distinguish between operational logs used for day‑to‑day troubleshooting and evidence‑grade records that must stand up under regulatory and legal scrutiny. The latter deserve stronger controls, stricter access and more disciplined monitoring, with design choices documented in artefacts you can reference in your A.5.33 evidence set.

Designing evidence‑grade RNG logging

Evidence‑grade RNG records should be designed to make undetected tampering or deletion extremely difficult. The goal is for any attempt to alter, delete or hide calls to be obvious long after the event, usually by combining append‑only storage, cryptographic integrity checks, strict time discipline and separate logging pipelines, all backed by clear change control and ownership.

Common measures include:

Append‑only storage: – write‑once, read‑many or immutability features so that records cannot be altered or deleted within their retention window.
Cryptographic integrity checks: – hashing or chaining of log entries, so that any change becomes obvious when you verify the chain.
Time synchronisation: – reliable, synchronised time sources so you can reconstruct sequences of events and correlate them with other systems.
Segregated logging pipelines: – forwarding RNG and key game events to dedicated log stores, separate from general application logs and operational noise.

From an engineering perspective, the cleanest way to enforce these controls is often through infrastructure as code and deployment pipelines. You can, for example, require that evidence‑grade logs are always written to approved, integrity‑protected destinations and that changes to logging configurations go through peer‑reviewed change control with recorded approvals.

Monitoring and alerting should then watch specifically for signals that threaten the integrity of RNG records, such as gaps in logs, changes to retention configurations or attempts to disable logging. In a regulated environment, it is prudent to validate these patterns against jurisdiction‑specific requirements with specialist advice and to capture the rationale in design documents that are explicitly referenced in your A.5.33 evidence pack.

Protecting game maths as a high‑value asset

Game maths artefacts encode the behaviour of your products and often represent significant intellectual property. At the same time, subtle changes to maths can alter RTP, volatility or edge in ways that are hard to spot in aggregate results, which makes them both a fairness risk and a regulatory concern if they are not controlled. Game maths combines commercial value with fairness risk, so it needs both strong secrecy and tight change control.

Effective protection of game maths usually includes:

Treating models, RTP calculations, symbol strips and configuration packs as highly sensitive information in your classification scheme.
Applying strict role‑based access control so that only a small, named group can view or change live maths.
Using robust version control and formal approvals for any change, with links to independent testing or certification.
Keeping your own copy of key evidence, even when third‑party studios or labs supply maths or certification outputs.

Where external labs or vendors are involved, A.5.33 still expects you to maintain adequate records over the lifecycle you control. Contracts should spell out who keeps what, for how long and in what form, and how you will both support future investigations or disputes. It is usually wise to seek jurisdiction‑specific legal advice when setting those terms and to store the agreed patterns with your architecture descriptions so they can be surfaced quickly during audits.

Once you have sound designs for logs and maths, the next challenge is deciding how long to keep each kind of record and how to balance fairness, regulatory and privacy expectations.

Classification and retention patterns that survive regulators

Record protection starts with knowing what you are keeping, how sensitive it is and how long you legitimately need it. In an ISO 27001‑aligned ISMS, information classification and records retention work together to give you that clarity for RNG logs, game maths and trading records, so that your approach remains defensible when regulators and auditors look closely. Classification and retention policies let you explain to regulators why you protect different fairness records in different ways and for different lengths of time and why some data is reduced or transformed to satisfy privacy rules.

A simple, consistent scheme helps you justify your choices to auditors, privacy regulators and gambling or financial authorities without having to reinvent your approach for every new product or territory. It also reduces internal confusion by making expectations visible to development, operations and compliance teams.

Applying confidentiality, integrity and availability thinking

For fairness‑related records, it helps to classify each type along three axes: confidentiality, integrity and availability. Looking at fairness records through these lenses makes trade‑offs transparent instead of accidental, letting you state clearly which record types must never leak, which must never change and which must always be retrievable within set time frames. It also helps you explain why some logs can be rotated quickly while others need hardened, long‑term storage.

In many operators the pattern looks roughly like this:

RNG logs: – usually medium to high confidentiality (they can expose internal designs), very high integrity and high availability for investigations and regulatory queries.
Game maths: – very high confidentiality (intellectual property and exploit risk), very high integrity and moderate availability (few people need frequent access).
Trading records: – high confidentiality (player or client data and financial positions), very high integrity and very high availability for AML, financial reporting and disputes.

A concise way to think about it is:

Record type	Confidentiality focus	Integrity / availability focus
RNG logs	Internal design and security detail	Replaying events and proving outcomes years later
Game maths	Intellectual property and exploit risks	Demonstrating intended behaviour and authorised change
Trading records	Player, counterparty and financial data	Supporting AML, reporting and dispute resolution

Once classification is clear, you can define retention patterns based on:

Licence and technical standards on fairness, dispute resolution and auditability.
Financial, tax and accounting rules on transaction records.
AML and counter‑terrorist financing obligations.
Data‑protection law, such as storage‑limitation principles under GDPR.

ISO 27001 does not dictate specific periods, but regulators will expect your rules to be grounded in these external requirements and in documented business needs. Internal audit and management review under Clauses 9.2 and 9.3 are where you test whether those patterns still make sense as your products, markets and obligations change.

Balancing retention with data protection principles

There is a real tension between long‑term fairness evidence and data‑protection expectations, especially where records contain personal data. Balancing these forces means thinking beyond “keep everything forever” or “delete everything quickly” and finding a defensible middle path you can explain clearly and consistently to gambling, financial conduct and privacy regulators.

Pragmatic patterns often include:

Keeping full, identifiable records only as long as needed for legal and regulatory purposes, such as AML and dispute windows.
Beyond that point, pseudonymising or aggregating data so that you can still analyse fairness and behaviour without retaining unnecessary personal detail.
Documenting your rationale, including the laws and standards you considered, in your legal and data‑protection registers.

Automation greatly reduces the risk of human error. You can tag datasets with classification and retention rules, use storage lifecycle policies to move data from hot storage to archive and then to secure destruction and apply legal holds when you know a dispute, investigation or litigation is under way.

A useful test is to take a real historic case – a dispute or regulator query – and ask whether, under your current classification and retention scheme, you would still have the necessary evidence. If not, your policies are not yet robust enough, regardless of how tidy they look on paper. Once you are comfortable with classification and retention, the final step is assembling an audit‑ready evidence set that shows how A.5.33 works in practice.

ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.

Book your demo

Building an audit‑ready evidence set for A.5.33

An audit‑ready A.5.33 evidence set is a curated bundle that shows how you design, operate and improve your records protection arrangements in a controlled, repeatable way. It packages your policies, designs and samples into a storey that makes sense to regulators and auditors, letting them see quickly what you do, why you do it and how you know it works, without drowning them in raw log files. Instead of handing over unfiltered data and hoping for the best, you present a clear line from requirements to design to operation and improvement, and you gain a reusable pack for complaints, inspections and licence renewals.

Rather than relying on a one‑off collection of exports each time someone asks a hard question, you assemble a structured storey: policies and designs at the top, operational samples in the middle and monitoring and improvement evidence underneath. In a mature environment you can show both that your design protects records and that day‑to‑day activity matches that design.

What an audit‑ready A.5.33 pack looks like

Most effective evidence packs for A.5.33 rest on four pillars that together tell a coherent storey about RNG logs, game maths and trading records. A strong pack uses these pillars to answer different questions: what you intend to do, how systems are built, how they behave in reality and how you keep improving them, giving auditors enough depth without overwhelming them.

Most effective evidence packs for A.5.33 rest on four pillars that together tell a coherent storey about RNG logs, game maths and trading records:

Policies and governance documents
These cover information classification and records management, specific procedures for handling fairness‑related records and the legal and regulatory registers that drive retention and protection decisions.
Design artefacts
Data‑flow and architecture diagrams show where records are created, how they move and where they are stored, alongside descriptions of logging, storage and backup designs and RACI charts that clarify ownership across the records assurance stack. These artefacts should explicitly reference decisions about integrity, immutability and retention.
Operational records and samples
Carefully redacted extracts from RNG logs, maths repositories and trading systems, sample walk‑throughs of real rounds or trades and change records for maths models and trading parameters demonstrate that your design is actually used.
Monitoring, testing and improvement evidence
Internal audit results, spot checks on completeness and access control, restore‑from‑backup test logs and records of incidents or disputes – together with the improvements you implemented – show that you monitor and refine your approach.

Visual: high‑level diagram of four evidence pillars, from policy down to monitoring and improvement.

This structure helps you prepare consistently and update the pack as your systems evolve, without having to start from scratch for every audit or regulator visit. It also aligns cleanly with ISO 27001 Clauses 9.2 and 9.3, which expect you to audit and review how well controls such as A.5.33 are working.

Questions auditors and regulators expect you to answer

When auditors and regulators look at A.5.33 in a gambling or trading context, they are often trying to answer a small number of practical questions. You can use those questions to stress‑test your evidence and close gaps early, because they care less about elegant diagrams and more about whether you can show complete records, controlled access, clear reconstruction of events and disciplined retention.

Common examples include:

Can you show that logs and records are complete for a given period and system, and that gaps would be detected?
Can you prove that only authorised people can alter or delete RNG logs, maths artefacts or trading histories, and that such actions are auditable?
Can you reconstruct the path from a specific player’s complaint or market dispute to the underlying technical events and decisions?
Can you demonstrate that retention and destruction are aligned with documented policies and external requirements, including data‑protection principles?

An ISMS platform like ISMS.online can make these questions easier to answer by linking A.5.33 control objectives to specific policies, diagrams and system evidences, providing consistent ways to store and index screenshots, exports, tickets and reports and supporting internal audits and management reviews focused on records protection.

When you reach this level of readiness, preparing for certification or a regulator visit becomes a matter of assembling and reviewing a known evidence pack rather than scrambling across multiple teams and systems each time. If you want help reaching that point, it is worth seeing how your own records would look inside a structured ISMS.

Book a Demo With ISMS.online Today

ISMS.online helps you turn ISO 27001 A.5.33 from a vague obligation into a practical, joined‑up view of the records that protect your games, markets and licences, so your team can see and manage fairness evidence as a coherent whole rather than a scattered set of logs and spreadsheets.

See your records through an ISO 27001 lens

If you want to move away from person‑dependent spreadsheets and ad‑hoc evidence packs, seeing your own records modelled in a structured ISMS can be eye‑opening. A short, focused session can walk through a fairness, dispute or regulator scenario that already matters to you and show how your RNG logs, game maths and trading records would be captured, classified and evidenced end‑to‑end in a single environment, rather than being spread across personal drives and ad‑hoc exports.

During that conversation you can explore how assets such as RNG logs, game maths artefacts and trading records become first‑class items in your ISMS, how each record type can be linked to legal and regulatory obligations and how controls and internal audits can be mapped back to those links. That makes it easier for you to demonstrate to stakeholders that A.5.33 is being addressed deliberately rather than informally.

Explore how ISMS.online fits your organisation

Default Description

Book a demo

Frequently Asked Questions

What does ISO 27001 A.5.33 actually expect you to prove about RNG logs, game maths and trading records?

ISO 27001 A.5.33 expects you to show that RNG logs, game maths and trading records are treated as formal records with owners, rules and evidence, not as “whatever the platform happens to be logging today.” In practice that means you decide which artefacts count as fairness or trading records, document that decision, and apply explicit controls for creation, storage, access, retention and destruction – all traceable inside your information security management system (ISMS).

For gambling and trading platforms this normally covers RNG configuration and call logs, maths versions and regulator‑approved test packs, and detailed bet or trade histories with prices, positions and settlements. Those records carry fairness, dispute, AML, licence and tax weight, so they need stronger integrity and availability protections than routine telemetry. You also need to be clear about who owns them, which obligations they satisfy, and how often you check that controls still operate as designed.

When you register these artefacts as assets inside your ISMS, you can link them to Annex A controls (including A.5.33), attach policies and procedures, and keep a small, curated evidence set that shows how each record type is generated, protected and used. A platform such as ISMS.online gives you one place to define which fairness and trading records exist, how they must be handled, and which samples and reviews prove that your storey holds up when a regulator or ISO auditor starts asking detailed questions.

How is this different from “we just keep all our logs for years”?

“Keep everything forever” feels safe but it is not what A.5.33 is asking for. The control is about deliberate, governed record‑keeping, which goes further than volume:

You decide which specific artefacts count as records and why they matter.
You set retention, access and integrity expectations per record type, not per storage system.
You show that these expectations are reviewed and adjusted as laws, licences and products change.

That shift from “lots of data somewhere” to “named records with known owners” is what convinces auditors that your fairness storey is robust rather than relying on heroic forensics when something goes wrong.

What should we document if we want auditors to take A.5.33 seriously?

Three small but powerful items usually change the tone of an audit:

A short policy that defines “fairness and trading records” (for example: RNG logs, maths packs, bet and trade histories) and explains why they are treated differently from general telemetry.
Asset‑register entries for each record family with owners, classifications, retention periods and key obligations (licence conditions, AML rules, privacy law, contracts).
Pointers from those assets to the controls and procedures that govern them – logging design, maths change control, data lifecycle, backup and restore.

ISMS.online can carry that structure for you: you add the record types once, link them to Annex A.5.33 and related controls, and attach example logs, maths packs and trade extracts. That way, when a reviewer asks “how do you meet A.5.33 for RNG logs?”, you open a single control record rather than hunting through emails and folders.

How should we classify RNG logs, game maths and trading records so they drive the right controls?

The most defensible approach is to classify RNG logs, game maths and trading records against confidentiality, integrity and availability (CIA) and then let that classification dictate how they are engineered and operated. ISO 27001 does not prescribe numbers or colours, but it does expect you to be able to explain why particular records are stored, protected and restored the way they are.

In gambling and trading environments, patterns tend to look like this:

RNG logs: – integrity and availability are very high (you must replay sequences and explain outcomes), confidentiality ranges from medium to high depending on how much they expose internal design or proprietary seeding techniques.
Game maths: – often sits at the upper end of confidentiality and integrity because it captures your edge; a leak or undetected change can be catastrophic.
Trading records: – combine high confidentiality (personal data, positions, strategies) with very high integrity and availability to support AML, reporting, complaints and tax.

A simple way to make this repeatable is to define a handful of CIA “profiles” such as “Restricted / Very High Integrity / High Availability” or “Highly Restricted / Very High Confidentiality / Very High Integrity” and assign each record family to one of them. You then translate profiles into concrete rules for encryption, access control, log retention, backup frequency, RPO/RTO, monitoring and restore testing. Once that mapping is set up in your ISMS, engineers no longer have to guess: they pick the right profile and the required controls come with it.

How does classification change day‑to‑day engineering behaviour?

Clear profiles turn fuzzy debates into predictable patterns. For example:

An RNG log marked “Very High Integrity / High Availability” naturally leads you toward append‑only storage, cryptographic checksums, clock‑synchronisation validation, frequent backups and stricter change control on logging configuration.
Maths classified as “Highly Restricted / Very High Integrity” pushes you to separate repositories, very narrow write access, mandatory peer review and explicit promotion paths into environments visible to regulators.
Trading records tagged “High Confidentiality / Very High Integrity / High Availability” justify strong encryption at rest and in transit, segregation from analytics or marketing stores, and tighter recovery objectives than general operational logs.

Because those behaviours are anchored to documented profiles in your ISMS, you can scale across new games, markets and teams without constantly re‑teaching first principles.

How do we keep classification in step with regulators rather than just our own risk appetite?

The resilient approach is to connect your classification scheme to a small legal and regulatory register:

For each record type, list the licence conditions, technical standards, AML rules, privacy obligations and contract clauses that apply.
Highlight the obligation that drives the strictest confidentiality, integrity or availability expectation.
Show how the chosen profile and associated controls satisfy that expectation.

In ISMS.online you can keep that register in the same place as your asset list, link each record type to its obligations, and update mappings when rules change. That makes it much easier to sit down with an auditor and say “here is how this retention rule, this integrity requirement and this access pattern flow directly from the combination of our licence, AML guidance and GDPR.”

How long should we keep RNG logs, game maths and trading records without colliding with privacy expectations?

ISO 27001 requires you to define and control retention, not to hit a particular number of years. In gambling and trading, other rulebooks set the floor: fairness rules, licence conditions, AML guidance, tax law and financial reporting standards typically expect you to be able to reconstruct behaviour and balances for several years. At the same time, privacy regimes such as GDPR expect you to minimise how long you keep identifiable personal data and to be able to justify your choices.

The practical way through is to treat retention as a record‑type design problem:

For each record family (RNG logs, maths packs, trade histories) find the strictest applicable requirement – for example, a seven‑year complaint or AML window.
Set your primary retention period to meet that requirement and document the sources you relied on.
Decide what happens next: can you pseudonymise identifiers, tokenize account references or aggregate data so you keep behavioural and fairness insight without indefinitely holding live personal data?

Your ISMS should carry both the reasoning and the rules: which record types exist, which obligations they answer to, how long you keep full detail, when you switch to reduced‑identifiability forms, and how you destroy data at the end of the lifecycle. ISMS.online can hold that mapping in a legal register, tie it to asset‑level retention rules, and then push those rules into recurring tasks so they actually happen instead of living in a policy PDF.

What does a sensible compromise between long‑term fairness analysis and privacy look like?

A pragmatic pattern that many regulators accept has two steps:

Primary window: keep fully identifiable records for the period driven by complaints, AML and financial reporting, with strong access control, logging and encryption.
Secondary window: after that period, move records into stores where direct identifiers are removed or replaced with pseudonyms or tokens. You still have enough structure to analyse fairness, volatility and behaviour, but everyday users can no longer map records straight back to named individuals.

A small, tightly controlled mapping between tokens and real identifiers can be kept for exceptional re‑identification (for example, under court order) and documented in your ISMS as a specific, audited control. That way, if a privacy regulator asks how you apply storage limitation, you can show more than “we thought it might be useful later.”

What evidence convinces auditors that retention is more than an aspiration?

Auditors usually look for a mix of design documents and live traces:

A brief standard that explains how you derive retention periods for each fairness and trading record type.
A table that links those record types to the specific laws, licences and contracts they support.
Examples of lifecycle events: scheduled pseudonymisation jobs, archive moves or secure deletion runs with timestamps and approvals.
Notes from periodic retention reviews where you looked at legal change, technical options and operational experience and made adjustments.

ISMS.online makes it easier to attach that material directly to A.5.33 and to the underlying assets, so you are not assembling it under pressure when the audit clock is ticking.

Which controls actually stop or expose tampering with RNG logs and game maths?

For A.5.33, “trust us, we would never change logs or maths” does not carry much weight. You need a visible combination of technical measures and process discipline that makes silent tampering hard, detection likely and recovery credible.

On the technical side, good practice for RNG logs usually includes:

Writing to append‑only or immutable storage (for example, object stores with write‑once settings or log‑structured filesystems).
Generating and periodically verifying cryptographic hashes or signed digests for log batches.
Enforcing accurate, synchronised clocks so sequences are consistent across systems.
Keeping RNG logging pipelines separate from general application logging so they are easier to monitor and restore.

For game maths, most regulators care more about change control, traceability and segregation:

Clear role separation between people who write maths, people who test it and people who approve and deploy it.
Version histories that let you see exactly what changed, when and by whom between the certified model and production.
Distinct, access‑controlled environments for development, testing, certification and live operation, with a narrow path between them.

Process then ties it together: you bring RNG logging and maths governance into the same change and incident routines you use for critical infrastructure. Changes to logging configuration or maths repositories go through peer review and approval; restore tests are planned; anomalies in log volume, retention settings or access are investigated and recorded. That storey is what brings A.5.33 from paper to practice.

Which specific signals do auditors and regulators tend to home in on?

You will usually see external reviewers relax when they recognise:

Immutability and integrity checks that are actually verified on a schedule, not just configured once.
Strict separation of duties for maths promotion, with a short, known list of approvers.
Demonstrated restore capability: for example, being able to recover RNG logs or trading data for a specified period within an agreed time.
Administrative logs showing who changed logging, retention or maths configuration, reviewed regularly rather than “for emergencies only.”

If those elements are visible inside your ISMS, backed by a few recent examples from production or test exercises, reviewers have a much easier job satisfying themselves that fairness evidence will survive both honest mistakes and hostile insiders.

How do we keep controls coherent as teams, games and markets multiply?

Growth tends to fragment good habits unless you pin them down centrally. Three patterns help:

Define baseline expectations for RNG logs, maths packs and trading records in your ISMS – for example, “all RNG logs must hit immutable storage within N minutes” or “all certified maths changes must carry approvals from these roles.”
Bake those baselines into secure development and change processes so new services are challenged to show compliance before going live.
Run light‑touch sampling: periodically select a game, market or product and check that logging, maths governance and trading record handling still match the baselines.

By capturing those checks and follow‑ups inside ISMS.online, you create a feedback loop: gaps are found, fixes are tracked, and future designs benefit. That’s exactly the kind of continuous improvement that ISO 27001 and sector regulators both look for.

What does a convincing A.5.33 evidence pack look like for ISO audits and gambling regulators?

The strongest A.5.33 packs are not the thickest; they are the ones that let a reviewer follow a single, coherent line from requirement to design to operation to learning. For RNG logs, game maths and trading records, a four‑layer structure usually works well:

Governance: – a small set of policies or standards that define the records, the obligations they support, ownership, classification and retention philosophy.
Design: – up‑to‑date diagrams and descriptions of where RNG output, maths versions and trades are generated, how they flow through systems, and which stores are authoritative.
Operation: – carefully redacted examples: real log slices, a few maths change records, short segments of trade histories, plus evidence of cryptographic checks, restores or lifecycle steps.
Oversight: – notes from internal audits, incident reviews and spot checks, including what you found and what you changed.

The aim is to arm an auditor to ask a focused question such as “show me how you would reconstruct a disputed spin from 30 months ago” and then walk them through the assets, controls and examples in minutes. If they can see the join between licence conditions, A.5.33, your record types and your stored evidence, your credibility rises quickly.

ISMS.online helps by letting you attach each of those artefacts straight to the Annex A control and the relevant assets: you log policies, diagrams, samples and review notes where auditors expect to find them. That beats sprinting through internal drives the week before a visit.

How do we avoid drowning auditors in screenshots and log dumps?

The temptation is to “prove everything”; the better tactic is to curate:

Start with a one‑page index for A.5.33 that explains what is in scope, which record types you cover, and where to look next.
For each type, provide small, representative samples – a single game or market, a short date range – that are easy to understand and explain.
Wrap samples in short narratives: what the reviewer is looking at, why it matters, how it connects back to your policies and design choices.

Then keep a deeper pool of material available if someone wants to drill down. That way auditors can build confidence quickly without losing time rummaging through raw exports.

How can we keep the evidence fresh so we are not always rebuilding it?

Treat your evidence set as a living part of the ISMS, not a separate project:

Give key items (policies, diagrams, sample sets) review dates and owners; update them when systems or obligations change.
Attach outputs from internal audits, incident reviews and restore tests to A.5.33 as you go, rather than summarising them once a year.
Retire obviously stale examples and replace them with snippets from more recent architectures or games.

ISMS.online can drive those reviews through scheduled tasks and change workflows, so you build “keeping A.5.33 up to date” into normal operations instead of relying on heroic effort before an external visit.

How should we align A.5.33 with gambling and financial regulations that pull in different directions?

RNG logs, game maths and trading records sit under multiple rulebooks at once. Gambling licences demand provable fairness, complaint handling and anti‑money‑laundering records. Financial regulations expect long‑term, reconstructable trade histories with clear client outcomes. Privacy laws insist on necessity, proportionality and rights such as access and erasure. ISO 27001 A.5.33 is the place where you show you have turned that tangle into a consistent record‑keeping design.

A practical way to do this inside your ISMS is to:

Build a register of obligations that touch fairness and trading data – licence conditions, regulator technical standards, AML rules, tax and reporting duties, privacy laws and key contract clauses.
Tag each record type (for example, RNG call logs, jackpot maths packs, FX trade blotters) with the obligations that apply.
For each type, decide and document how you will meet: minimum retention, integrity and availability expectations; maximum acceptable identifiability over time; and any special access or reporting duties.

You can then explain, for example, that RNG logs are retained in an immutable store for the licence‑driven complaint period, that trade histories satisfy AML and financial reporting windows, and that personal data in those records is pseudonymised or removed when it is no longer necessary for those purposes. When that logic is captured in ISMS.online and reflected in linked assets and controls, regulators and ISO auditors are much more likely to see your implementation as a single, thought‑through system rather than a patchwork of local fixes.

What should we do when rules overlap or seem to clash?

Overlaps and tensions are normal. The key is to make your reasoning visible:

For each record family, identify the obligation that drives the longest retention, the strongest integrity or the tightest access requirement and design to meet or exceed that while respecting privacy principles.
Where very long retention windows exist, apply stronger technical and organisational measures – for example, encryption, strict role‑based access control, location limitations and more aggressive pseudonymisation over time.
If you find a real conflict that cannot be fully resolved in technology or process, document the trade‑off, any legal advice you obtained, attempts to seek regulator guidance and the mitigations you put in place.

Auditors and regulators generally respond better to “here is the documented dilemma and what we did about it” than to silence or hand‑waving. Making that storey part of A.5.33, rather than hiding it in email threads, shows that you take both security and compliance seriously.

How do we keep alignment as law and licence conditions change year by year?

The regulatory environment for gambling, trading and data protection is not stable. To keep A.5.33 aligned, you need a small, repeatable loop:

Keep your obligation register current and linked to record types and controls; update it when licences, AML guidance or privacy rules change.
Trigger impact assessments on affected records when a significant change lands, and record any required updates to retention, storage, access or lifecycle controls.
Use management review and internal audit cycles to check that those updates have been implemented and to surface any practical friction.

ISMS.online is designed to support that loop: you can tie legal updates to specific assets and controls, raise work items to adjust designs or procedures, and then attach evidence once changes are live. That makes it much easier to show, under scrutiny, that your approach to A.5.33 evolves with the rulebook instead of lagging behind it.

ISO 27001 A.5.33 – Protecting RNG Logs, Game Maths & Trading Records