ISO 27001 A.8.28: Secure Coding for Fair, Trustworthy Gambling Engines

Why secure coding has become a fairness control in online gambling

Secure coding has become one of your core fairness controls because, in a modern gambling stack, software now determines randomness, game presentation and betting outcomes. Under ISO 27001 A.8.28 it therefore sits alongside your fairness controls, not just your IT hygiene: weaknesses in that code can be exploited by attackers, misused by insiders or behave unpredictably under load, and even small defects can look like rigged games, trigger disputes and bring intense regulatory attention. When regulators, labs and licencing bodies examine your platform, they increasingly treat code quality as part of overall game integrity.

Players judge fairness through experience, but regulators judge it through your code and evidence.

How insecure code shows up as “unfair play” in the real world

Insecure code in gambling platforms usually surfaces as apparently unfair play rather than classic data theft. Players and regulators experience glitches, patterns and settlement errors as signs that games are not properly controlled, even if you see them as isolated defects.

A weak or mis‑used RNG can be reverse‑engineered so that a determined attacker predicts outcomes ahead of time. A game client that trusts its own local state might let a player replay winning sequences by replaying captured traffic. A settlement bug might pay out twice on a voided market or fail to settle certain edge cases at all. Each of these is traceable back to coding decisions: choice of libraries, where logic runs, how inputs are validated and how changes are tested before release.

Thinking about these scenarios makes the risk concrete. A high‑profile dispute that forces you to void a set of results or manually compensate players can easily erase the margins on an entire campaign. If a regulator comes to see your platform as unreliable, you risk licence conditions, additional reporting or even suspension. Even when the root cause is a subtle logic issue, the storey in the market is simple: the code was not robust enough to protect players. Secure coding takes those stories seriously and designs them out up front.

What changes when you view A.8.28 as revenue protection

Viewing A.8.28 as revenue protection lets you justify secure coding in commercial terms, not only in compliance language. You compare modest investment in review and testing with the cost of voided markets, lost licence trust or long‑running abuse.

When you reframe A.8.28 this way, conversations with executives and product teams change tone. Instead of arguing about how much secure coding costs, you ask what it would cost to unwind weeks of bets because of an RNG or settlement flaw, or how a bonus‑abuse ring exploiting a client‑side weakness for months would affect revenue and reputation. Suddenly, time spent on threat modelling, code review and targeted testing looks like cheap insurance.

This framing also clarifies where to focus. Not every piece of code is equally risky. A static marketing page and a jackpot calculation module do not deserve the same level of scrutiny. A.8.28 gives you a basis for saying: RNGs, game clients and betting engines are high‑risk components; they must follow stricter secure coding patterns, go through deeper review and carry richer evidence trails. Lower‑risk software can follow lighter processes.

Finally, treating A.8.28 as fairness‑critical helps you connect signals across the business. Player complaints, affiliate feedback, anomalous win‑loss patterns and chargeback spikes are no longer just customer‑service or finance issues; they become triggers for engineering to re‑examine coding assumptions, randomness handling and settlement paths. That is how a management‑system control turns into day‑to‑day improvement, rather than a document that is only opened at audit time.

Book a demo

What ISO 27001 A.8.28 really requires in plain language

ISO 27001 A.8.28 requires you to define what secure coding means for your organisation, train people to apply it, embed it into your development lifecycle and keep evidence that it happens in practice. In plain language, that means translating high‑level security expectations into concrete coding rules, ensuring people understand and follow them and being able to show auditors and regulators how that works day to day, especially around sensitive components such as RNGs, game clients and betting engines, where secure coding has to be clearly visible around critical game components rather than buried in generic web applications.

Secure coding turns broad security expectations into repeatable development habits your teams can actually follow.

The four core duties in A.8.28

A.8.28 sets out four core duties that give you a practical checklist for secure coding across your stack. When you express them clearly and link them to day‑to‑day work, it becomes easier for developers and auditors to see how the control is applied to real systems such as RNGs and betting engines.

Define secure coding standards: Clear rules for languages, frameworks and gambling‑specific risks.
Equip people to apply them: Training plus embedded guidance in reviews, templates and tools.
Embed into the lifecycle: Security tasks built into design, build, test and deployment.
Keep and use evidence: Concrete examples that show standards are followed and improved.

Defining what secure coding means in your context usually takes the form of written secure coding standards and patterns that reference recognised sources such as OWASP, language‑specific guidance and sector expectations from gambling labs and regulators. For gambling platforms, those standards should include very specific rules about randomness, game logic location, client trust boundaries and transaction handling.

Equipping people to apply those principles means more than a one‑off training session. You train developers, architects and testers, but you also embed guidance where they work: pull‑request templates, code‑review checklists, library usage patterns and threat‑modelling prompts. Classroom sessions alone do not satisfy A.8.28; you need to see the principles show up in day‑to‑day work.

Baking secure coding practices into the secure development lifecycle connects A.8.28 with A.8.25, the broader secure development control. For gambling systems, that might mean risk‑based threat modelling for new games, mandatory security reviews for RNG and betting‑engine changes and defined security tests in your pipelines. Secure coding is then a normal part of delivery, not an afterthought.

Keeping evidence closes the loop. Policies and standards are not enough. Auditors and regulators will expect to see examples of reviewed code, test reports, treatment of discovered defects and outputs from external labs or independent assessments. For high‑risk components like RNGs and betting engines, those evidence trails need to be particularly solid and consistently maintained.

How A.8.28 fits alongside regulators, labs and sector standards

A.8.28 is most effective when you treat it as the engineering layer under your gambling regulations and lab standards. Regulators define what fairness and integrity must look like, labs test whether specific builds meet those expectations and secure coding governs how you write, review and change code so those outcomes stay reliable over time.

In gambling, you are already subject to technical standards from regulators and detailed testing regimes from independent gaming labs. Those frameworks talk about RNG quality, game integrity, secure remote communication, configuration control and change management. Secure coding is the engineering discipline that makes those obligations real.

You can think of it this way: regulators and labs often say what you must achieve, such as ensuring that an RNG is unpredictable and tamper‑resistant or that clients cannot interfere with game outcomes. ISO 27001, and A.8.28 in particular, ask how you run your organisation so that you reliably achieve that outcome over time. If you can show that your secure coding standards incorporate regulator and lab expectations, and that your secure development lifecycle enforces those standards, you are in a much stronger position during both ISO audits and regulatory inspections.

This is where an information security management platform such as ISMS.online can help. Rather than keeping secure coding rules in a static document, you can link them directly to your risk assessments, development workflows, training plans and audit evidence. That way, when an auditor asks how A.8.28 is applied to your RNG or sportsbook engine, you can walk through a single, coherent storey rather than hunting through scattered files.

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

Applying A.8.28 to RNG design and implementation

Applying A.8.28 to RNGs means treating them as security‑relevant components whose algorithms, seeding, configuration, access and change control are all rigorously managed. Secure coding for random number generators in gambling requires you to go beyond passing statistical tests and demonstrate that the code uses appropriate algorithms, seeds them securely, protects their state, resists tampering or misuse and keeps those design decisions explicit, documented and subject to ongoing review so protections meet gambling expectations over time.

Independent labs and regulators already expect you to prove RNG quality and robustness. When you align those expectations with your secure coding standards and lifecycle, test reports and certifications become powerful evidence that A.8.28 is working in practice, not just on paper.

Visual: High‑level data flow from RNG services into game logic, then out to clients and wallets.

Choosing the right RNG construction

Choosing the right RNG construction starts with understanding where randomness matters most and committing to vetted, security‑appropriate designs for those cases. In practice, secure coding usually means relying on proven cryptographic libraries or platform APIs rather than writing your own RNG logic.

For each product type you operate, you should decide what kind of RNG construction is appropriate and record that as part of your secure coding standard. Many operators use cryptographically secure pseudorandom number generators or deterministic random bit generators that are based on well‑studied designs and, in some cases, national guidance. Hardware RNGs may supplement these for entropy, but the deterministic core still needs careful engineering.

From a coding perspective, secure practice usually means using a vetted cryptographic library or platform API rather than writing your own RNG. You specify which APIs are permitted for security‑relevant randomness, which are only acceptable for non‑critical uses such as visual effects and which must never be used. You explain why: for example, that a general‑purpose PRNG designed for simulations is not safe for card shuffling or slot outcomes.

The design record should cover more than just the algorithm name. It should describe where the RNG runs, such as in a central service or per‑game service, how it is initialised, which systems can call it and how results are consumed. That design then feeds into threat modelling and code review so that weaknesses, such as shared RNG state between games, are spotted early rather than by an external assessor.

Seeding, entropy and protecting RNG state

Strong RNG seeding and state protection are just as important as the algorithm choice. Secure coding under A.8.28 expects you to define acceptable entropy sources, reseeding strategies and protections against state exposure in a way developers can follow and reviewers can test.

Even the best RNG algorithm fails if you seed it poorly. Secure coding under A.8.28 expects you to think through seeding and entropy in a structured way. That starts with identifying your entropy sources: operating‑system pools, hardware noise sources or carefully constructed non‑physical sources. You then decide how seeds are derived from those sources, how often reseeding happens and how you detect and handle entropy failures.

You should ban weak patterns explicitly. Time‑based seeds, predictable counters or fixed seeds for production systems have no place in gambling RNGs. Your standards and code‑review templates can spell this out, so reviewers know to look for calls that bypass approved seeding functions or use dangerous defaults.

Protecting RNG seeds and internal state is just as important. That includes access control on any files or devices used for entropy, memory‑handling practices to minimise exposure of state and architectural decisions so that client‑side code never sees raw RNG state. Good secure coding practice also covers error handling and logging: you avoid writing seeds or internal values to logs, and you ensure that diagnostic modes cannot be left enabled in production environments.

Finally, A.8.28 expects that your RNG implementation and configuration are subject to independent review. In gambling this often means third‑party lab testing and certification. Secure coding practice is to treat those external assessments as part of your own control system: you record which code and configurations were tested, you manage changes against that baseline and you make sure developers understand what would invalidate the certification.

Secure coding for game clients: web, mobile and desktop

Secure coding for game clients means assuming every client environment is hostile and designing your software so that no single compromised device can decide outcomes or steal value. For browser, mobile or desktop clients, secure coding under A.8.28 expects you to treat the client as untrusted and ensure that a compromised or automated client cannot meaningfully undermine fairness or security: critical decisions and randomness move to the server, and all client input is treated as untrusted and carefully validated.

For game clients, secure coding under A.8.28 means assuming the client environment is hostile and designing your software so that a compromised client cannot meaningfully undermine fairness or security. That applies whether your client is a browser‑based game, a native mobile app or a desktop launcher. The client can still provide a rich player experience, but it must not be a single point of failure for game integrity or bet security.

Treating the client as untrusted by design

Treating the client as untrusted means drawing a hard line between presentation and authority. The client collects inputs and shows results, but your servers decide outcomes, check limits and settle bets.

The most important secure coding pattern for game clients is to keep authoritative decisions on the server. RNG calls, odds calculations, bet acceptance, settlement and payouts all belong there. The client requests actions and displays results, but it never decides outcomes. This server‑authoritative approach reduces the damage that a modified or automated client can do.

On top of that, you validate all client inputs on the server. That includes obvious fields such as stake amounts and bet selections, but also subtler aspects such as timing, sequence numbers and device or session identifiers. Your server‑side code assumes that any client request could be replayed, reordered or crafted, and it contains logic to detect and reject those patterns.

In code, that means avoiding shortcuts such as calculating winnings purely on the client or relying on client‑side flags to represent game state. It also means designing APIs that are robust in the face of missing or conflicting data. For example, a settlement endpoint should not accept arbitrary outcomes from the client; it should compute outcomes itself based on server‑side event data.

Defending against tampering and man‑in‑the‑middle attacks

Defending game clients against tampering and man‑in‑the‑middle attacks means hardening transport security, protecting code integrity and building protocol‑level safeguards against replay and injection. Once decisions live on the server, these measures reduce the impact and visibility of client‑side compromise.

Once you have treated the client as untrusted, you still need to prevent or limit tampering and network attacks. For web clients, modern transport security is the baseline: use current protocol versions, disable outdated cyphers, enforce secure cookie flags and apply security‑related headers to reduce downgrade and injection risks. For mobile and desktop clients, you can additionally use certificate validation hardening and, where appropriate, certificate pinning to make interception harder.

Integrity of the client code and configuration is another concern. Secure coding patterns here include code signing for installers and binaries, integrity checks for downloaded assets and cautious use of obfuscation or anti‑tamper libraries for high‑risk logic. You balance these controls against usability, platform guidelines and privacy expectations, particularly on mobile platforms where invasive anti‑cheat techniques can generate negative publicity.

Man‑in‑the‑middle risks are not limited to raw transport. Attackers may try to replay captured requests to duplicate bets or exploit race conditions. To counter that, your protocols should incorporate unique identifiers, nonces or sequence numbers, and your server‑side code should treat duplicates or out‑of‑order messages with care. Logging and monitoring then help you spot patterns that suggest bots, traffic manipulation or widespread client compromise.

Secure coding for clients also encompasses telemetry. You decide in advance what signals you need to detect abuse, such as impossible click rates, multi‑session patterns from a single device or inconsistent client versions, and design your code to emit those signals in a privacy‑conscious way. That gives your fraud and security teams the raw material to act on, without retrofitting logging in a crisis.

Visual: Simple architecture sketch showing server‑authoritative game logic, untrusted clients and monitored API boundaries.

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

Book your demo

Architecting and coding betting engines securely

Architecting and coding betting engines securely means recognising them as high‑risk systems where small defects can cause outsized financial and regulatory damage. These engines embody your most sensitive business logic – they set and update odds, accept and modify bets, apply limits and rules and settle outcomes into wallets – so secure coding under A.8.28 requires carefully modelled workflows, disciplined coding patterns for pricing and settlement logic and strong change control, so every decision can be defended to auditors, regulators and customers and subtle manipulation or logic flaws are less likely to slip through.

Betting engines embody the most sensitive business logic in your platform. They set and update odds, accept and modify bets, apply limits and rules and settle outcomes into wallets. Secure coding under A.8.28 treats these engines as high‑risk systems whose behaviour and changes must be tightly controlled. Here, the goal is not only to prevent classic vulnerabilities but also to protect against subtle manipulation and logic flaws.

Independent testing and certification of betting engines, combined with clear coding standards and review trails, provide some of your strongest fairness evidence. When you can show that sensitive markets pass through well‑defined checks before and after release, regulators and partners gain confidence that your platform does not depend on luck or heroics.

Visual: Workflow diagram from odds feeds and trader tools through betting engine, settlement and wallet updates.

Protecting odds calculation and settlement logic

Protecting odds calculation and settlement logic starts with a clear, shared model of how bets flow through your systems. You then encode that model in consistent, well‑reviewed code paths that validate inputs, handle edge cases predictably and recover safely from missing data or timing anomalies.

The first step is to model your betting workflows clearly. For each product line, you map how odds are generated, who or what can adjust them, when bets are accepted or rejected, how voids and cancellations work and how settlement interacts with external data feeds. That model should be detailed enough that you can identify abuse cases, such as who could deliberately misconfigure a market or how an attacker could exploit timing between feed updates and bet acceptance.

In code, you then apply secure coding principles to this logic. You avoid duplicating complex rules across multiple services or code paths, which often leads to inconsistencies. You validate all external inputs, including odds and results feeds, and you design default behaviours for missing or conflicting data that err on the side of safety and compliance. You watch for race conditions and ordering issues, especially where live prices and in‑play bets are involved.

Change management is crucial. Under A.8.28, changes to critical business logic are not just feature work; they are security‑relevant. You define which kinds of change require peer review, dual approval or sign‑off from risk or compliance roles. You ensure that emergency fixes still pass through a minimal, documented process rather than being patched directly in production. In code‑review templates, you add questions that explicitly ask about fairness and abuse scenarios, not just code style.

Step 1 – Model betting workflows and abuse cases

Map how odds, bet acceptance, voids and settlements work, then identify where mistakes or deliberate abuse could occur.

Step 2 – Implement logic in controlled, consistent code paths

Keep pricing and settlement rules in well‑defined services, validate all external inputs and define safe defaults for missing or conflicting data.

Step 3 – Apply strict change control to critical logic

Require structured review, approvals and traceable change records for any modification to betting workflows, limits or settlement behaviour.

Ensuring transaction integrity and non‑repudiation

Ensuring transaction integrity and non‑repudiation means designing your betting engines so you can reconstruct what happened to any wager at any time. Secure coding supports this by favouring append‑only event logs, consistent identifiers and robust access controls, so you can prove a bet was processed correctly and detect tampering attempts quickly.

Secure coding for betting engines must also deliver transaction integrity and non‑repudiation. That means being able to show, after the fact, that a bet was recorded correctly, processed according to the rules in force at the time and settled in line with published terms. If you cannot reconstruct that storey from your logs and data structures, you will struggle to defend yourself in disputes or investigations.

At the code and architecture level, you can design for this in several ways. Using append‑only logs or event‑sourcing patterns for bet lifecycle events helps ensure that changes are recorded rather than silently overwritten. Applying cryptographic hashes or signatures to critical records can provide tamper evidence. Ensuring that time, market and rule identifiers are captured consistently across systems allows you to correlate events even when different services or teams are involved.

Access control plays a major role here. Role‑based access control and least‑privilege principles should be applied not only to customers but to internal users and services. Traders, risk analysts, customer support staff and developers should all have clearly defined permissions, with sensitive operations such as odds model changes or settlement overrides subject to strict controls and logging. A.8.28 interacts closely here with other Annex A controls on access management and logging, so you should design your code and services with those patterns in mind.

Regular validation and back‑testing of pricing models and settlement behaviour, particularly around edge cases and promotions, rounds out the picture. While much of this work sits in product and quantitative teams, secure coding practice is to recognise it as part of your control system rather than a purely business exercise. That means capturing test cases, expected behaviours and regression results in ways that auditors and regulators can understand.

How A.8.28 interacts with other Annex A controls and gambling rules

A.8.28 works best when you see it as one piece of a wider development and assurance cluster. It is just one control in a group of development‑related requirements, sitting alongside secure development, application security requirements, testing, supplier management and regulatory obligations; when you connect these, it becomes easier to design a coherent system in which secure coding supports gambling rules from regulators and labs and a single set of artefacts satisfies multiple expectations.

A.8.28 is just one control in a cluster of development‑related requirements. To make it work in practice, you need to see how it connects to secure development, application requirements, testing, supplier management and regulatory obligations. When you line these up, it becomes easier to design a coherent system in which a single set of artefacts supports multiple expectations, including those from gambling regulators and labs.

Linking secure coding to secure development and testing controls

Linking secure coding to secure development and testing controls helps you avoid duplicate processes and gaps. You can treat A.8.25, A.8.26, A.8.28 and A.8.29 as a single storey: how you plan work, define requirements, write code and prove it behaves fairly and securely.

Several Annex A controls naturally sit alongside secure coding. At a high level, secure development lifecycle requirements give you the process framework; secure coding defines what needs to happen inside those processes; and testing controls verify the results. For gambling systems, this cluster is particularly important because changes to software are often under the direct scrutiny of regulators and independent gaming labs.

The table shows how key Annex A controls relate to secure coding activities in a gambling context.

Control	Core question it answers	Gambling‑specific emphasis
A.8.25 Secure development lifecycle	How do you plan, build and maintain software securely?	Risk‑based SDLC for RNGs, clients, engines and supporting services
A.8.26 Application security requirements	What security and fairness requirements must applications meet?	Explicit requirements around randomness, integrity, limits and responsible gambling
A.8.28 Secure coding	How do you write and review code to avoid vulnerabilities and logic flaws?	Coding patterns and standards for RNGs, client trust boundaries and betting logic
A.8.29 Security testing	How do you verify that applications behave securely in practice?	Targeted testing of RNG usage, client tamper resistance and betting workflows

When you design your development practices and evidence model, it is efficient to produce artefacts that satisfy all of these questions together wherever possible. A single threat model for a new game might feed application requirements, secure coding checklists and test plans. A code‑review record might show alignment with both A.8.28 and regulator expectations. A penetration test report on your betting engine might be referenced under testing, secure coding and risk treatment.

Aligning ISO 27001 with GLI, eCOGRA and remote technical standards

Aligning ISO 27001 with GLI, eCOGRA and remote technical standards allows you to satisfy sector‑specific fairness and integrity expectations without recreating separate control systems. By mapping lab and regulator requirements onto Annex A controls, particularly A.8.28, you can show that the same engineering discipline supports both certification and ongoing oversight.

Beyond ISO 27001, gambling operators must satisfy sector‑specific frameworks: remote technical standards from regulators and detailed testing criteria from labs such as GLI or eCOGRA. These frameworks often focus on fairness, integrity, change control and security around gaming systems. Aligning them with your Annex A view can significantly reduce duplication and confusion.

A practical starting point is a mapping document that links key regulator and lab requirements to ISO controls. For example, RNG certification criteria can be linked to secure coding standards, development lifecycle controls and testing controls. Remote technical standards around secure communications and change management can be tied to application requirements, access control, logging and supplier management. Doing this once and keeping it in your information security management system means everyone sees the same picture: developers understand which expectations apply to their code, compliance teams see where evidence comes from and auditors can follow the trail.

Secure coding is a crucial part of that map. Many regulator and lab requirements implicitly assume that code is written, reviewed and maintained in a disciplined way. If you can show that A.8.28 has been implemented with these sector expectations in mind, you can often satisfy multiple obligations with one set of practices and artefacts. Conversely, if your secure coding rules ignore gambling‑specific risks such as RNG misuse, client tampering or settlement edge cases, you will find yourself building parallel, inconsistent controls just to get through assessments.

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

Book your demo

Turning A.8.28 into a living part of your SDLC and audits

Turning A.8.28 into a living part of your secure development lifecycle means integrating secure coding into pipelines, change processes and incident response, rather than treating it as a static policy. The final step is to make secure coding for RNGs, game clients and betting engines part of how you build and operate software every day by defining what counts as acceptable evidence, wiring that into your DevSecOps toolchain and setting up feedback loops so incidents and findings translate into better code, making ISO 27001 certification and regulator audits natural outputs of good engineering practice instead of separate projects.

The final step is to make secure coding for RNGs, game clients and betting engines a living part of how you build and operate software, not a static stack of documents. That means integrating A.8.28 into your DevSecOps toolchain, defining what counts as acceptable evidence and setting up feedback loops so incidents and findings translate into better code. When you do this well, ISO 27001 certification and regulator audits become outputs of good engineering practice rather than separate projects.

What good evidence for A.8.28 looks like in a gambling audit

Good evidence for A.8.28 in a gambling audit is specific, practical and clearly linked to your high‑risk systems. You want to show how standards, training, reviews, testing and independent assessments come together around RNGs, clients and betting engines, rather than relying on generic documents or assumptions.

From an auditor or regulator’s perspective, strong A.8.28 evidence has several characteristics. It is specific to your systems, shows how policies are applied in practice and covers both technical and organisational aspects. For gambling platforms, examples might include:

Secure coding standards covering RNG usage, client trust boundaries and betting logic, with version and approval history.
Training records for developers, testers and architects on secure coding and gambling‑specific security topics.
Code‑review or pull‑request histories that highlight security and fairness checks for high‑risk components.
Outputs from static analysis, dependency scanning or fuzzing tools, plus records of how you triaged and fixed findings.
Penetration‑test and independent lab reports on game fairness, client tampering and betting workflows for defined releases.
Change‑management records that show how urgent fixes were controlled and folded into standard processes.

An information security management platform like ISMS.online can make it much easier to collect and present that evidence. By linking policies, risks, controls, development activities and external reports in one place, you can generate a coherent narrative for auditors and regulators. Instead of hunting across multiple tools and wikis, you can demonstrate how A.8.28 is expressed in your standards, applied in your workflows and checked via testing and independent assessment.

Embedding secure coding into DevSecOps without slowing delivery

Embedding secure coding into DevSecOps without slowing delivery depends on scoping effort to real risk and automating checks wherever possible. You give your highest‑risk systems deeper controls and evidence, while lighter‑risk components follow proportionate rules that keep delivery moving.

Many teams worry that adding secure coding controls will slow them down. Under A.8.28, the answer is not to bolt on heavy manual steps, but to integrate security checks into the automation you already use. That starts with risk‑based scoping: you focus deeper controls on the parts of your system where bugs have the highest impact, such as RNG services and betting engines, and you keep controls for low‑risk code proportionate.

In your pipelines, you can add automated checks that enforce basic secure coding rules. For example, pipelines can block builds that introduce prohibited randomness APIs, remove required tests or bypass code review on specified directories. Security tests for particular modules can run as part of continuous integration rather than as a separate, infrequent exercise. At the same time, you preserve room for human judgement via targeted threat‑modelling workshops and manual reviews on truly high‑risk changes.

A simple improvement loop often looks like this:

Step 1 – Define and refine secure coding standards

Agree risk‑based standards for RNGs, clients and betting engines, and keep them up to date as incidents and regulations evolve.

Step 2 – Integrate standards into tooling and workflows

Bake checks into repositories, templates and pipelines, so secure coding rules are applied automatically wherever possible.

Step 3 – Feed incidents and findings back into the standards

Use production incidents, lab findings and audit results to adjust standards, checklists and automation, closing the learning loop.

Feedback loops are vital. Incidents, audit findings and lab observations should feed into updates to your coding standards, patterns and automation. If a particular class of bug slips through repeatedly, you can add a checklist item, a lint rule or a test pattern to catch it earlier. Over time, this continuous improvement is what convinces both auditors and your own leadership that A.8.28 is working as intended.

ISMS.online can underpin this by acting as the backbone that connects policies, risks, controls, projects and evidence. When you change a standard or introduce a new gating rule for RNG code, you can reflect that in the information security management system, assign responsibilities and track completion. That way, your DevSecOps evolution stays aligned with your ISO 27001 obligations rather than drifting into a parallel universe.

Book a Demo With ISMS.online Today

ISMS.online helps you see how secure coding, fairness and ISO 27001 can sit together in one practical system so you can protect players, licences and revenue without slowing delivery. It turns ISO 27001 A.8.28 from a line in a standard into a visible, auditable part of how you build and run your gambling platform by giving you a structured environment to define secure coding standards, map them to specific systems such as RNGs, clients and betting engines, link them to risks, controls and projects and capture real training, review, testing and supplier‑check evidence as work happens.

How ISMS.online helps you operationalise A.8.28 for gambling platforms

ISMS.online helps you turn ISO 27001 A.8.28 from a line in a standard into a visible, auditable part of how you build and run your gambling platform. The platform gives you a structured environment to define secure coding standards, map them to specific systems such as RNGs, clients and betting engines, and link them to risks, controls and projects. You can capture training plans, code‑review approaches, testing strategies and supplier checks in one place, then attach real evidence as work happens.

From a leadership and compliance perspective, that means you can answer difficult questions with confidence. When an auditor asks how A.8.28 is applied to your main sportsbook engine, you can show the secure coding standard, the risk assessment, the change history and sample evidence from reviews and tests. When a regulator wants to understand how you ensure RNG changes are properly controlled, you can walk through the same coherent storey without pulling data from multiple systems.

Crucially, ISMS.online is designed to complement, not replace, your existing developer and security tools. You continue to use familiar repositories, ticketing systems and CI/CD pipelines, while the information security management system provides the governance, mapping and reporting layer that ISO 27001 and regulators expect. That balance helps you improve assurance without adding unnecessary friction to delivery.

What a low‑friction pilot could look like for your team

A focused pilot helps you test whether ISMS.online genuinely reduces effort around A.8.28 before you commit to wider rollout. You can start with one or two critical services, such as the main RNG and primary betting engine, and see how quickly you can centralise standards, risks and evidence for them.

You do not need to transform your entire organisation in one step to see value. A sensible approach is to pilot ISMS.online around one or two critical services: for example, your primary RNG service and your main betting engine. You define or refine the secure coding standards that apply to them, map existing development and testing practices into the platform and start capturing evidence from real changes and assessments.

Over a short period, you can then test how well this setup supports typical challenges. Can you assemble material for an internal or external audit in hours rather than weeks? Can you show how an incident or lab observation translated into updates to coding standards or pipeline checks? Can you give your board a clearer view of fairness and security controls without manual slide‑building?

As you gain confidence, you can extend the model to other parts of your stack and additional frameworks, including privacy and business continuity. Throughout, you retain clear measures of success: reduced audit preparation effort, fewer repeat findings around software security and faster, safer rollout of secure coding improvements across RNGs, game clients and betting engines.

If you operate multi‑jurisdiction gambling platforms with RNG‑heavy portfolios and want to protect players, licences and revenue while keeping your teams moving quickly, it is worth exploring how ISMS.online can support you. A short, tailored session that walks through your architecture and regulatory landscape will show exactly how A.8.28 and the rest of Annex A can become practical, lived parts of your development culture rather than abstract obligations on paper.

Book a demo

Frequently Asked Questions

How does ISO 27001 A.8.28 shape everyday work on a gambling platform?

ISO 27001 A.8.28 shapes everyday work by making “secure by default” the normal way your teams change anything that touches fairness, balances, or licence obligations. In practice, it should be visible whenever someone raises a ticket, writes code, reviews a change, or closes an incident on your RNGs, betting engines, wallets, or game clients.

Where should secure coding actually show up in a normal week?

Think in terms of routine activities, not an annual audit exercise:

1. When work is first scoped and picked up

New features or fixes that touch high‑impact areas (RNGs, settlement, wallets, reporting) are:
Tagged as “fairness/balance‑sensitive” in your backlog.
Routed through a short, standardised design step that forces decisions on:
Allowed RNG libraries and APIs.
Where outcomes, odds, and settlements are calculated.
Which limits, promotional rules, and reporting duties apply.
Storey or ticket templates link directly to:
Your secure‑coding standard for that stack.
Any gambling‑specific patterns (for example, payout caps, time‑zone edge cases).

So A.8.28 is present before a line of code is written.

2. During development and peer review

Developers work with:
IDE snippets or starter files that already follow your secure‑coding conventions.
Checklists in pull‑request templates that call out randomness, trust boundaries, and money flows.
Pull requests that touch “fairness code”:
Must be reviewed by someone who understands both security and gambling risk.
Document what could go wrong if a change behaves unexpectedly (for example, mis‑priced accumulators, jackpot race conditions).
Are rejected if they introduce unsafe RNG usage, duplicated pricing logic, or bypass existing limits.

Routine reviews become one of your strongest A.8.28 controls.

3. Inside CI/CD and release decisions

Pipelines for high‑impact components do more than run unit tests:
Static and dynamic analysis stages block known dangerous patterns.
Fairness or property‑based tests run automatically on new or changed RNG and pricing code.
Promotions to production require visible approvals for changes that affect exposure or player outcomes.
Build artefacts, approvals, and test reports are:
Automatically linked to the change.
Easy to surface later to auditors and regulators.

This is where an information security management system or Annex L‑aligned integrated management system pays off: a platform such as ISMS.online lets you join pipelines, approvals, and Annex A.8.28 records so you are not stitching that storey together manually.

4. When something goes wrong

For incidents or near‑misses involving fairness, balances, or reporting, post‑incident reviews always ask:
Which secure‑coding expectations should have applied?
Where did they fail, or where were they missing?
What do we change in standards, tooling, training, or workflow?
Those actions are:
Tracked as work.
Linked back to A.8.28, relevant risks, and other Annex A controls.

Over time, that feedback loop is evidence that secure coding is improving based on real experience, not sitting still in a policy document.

5. In how you hold and show evidence

Day to day, the most powerful sign that A.8.28 is “how you work” is that:

For any important component-say one jackpot game or a main sportsbook engine-you can:
Show the standards it follows.
Pull the training and competence records for the team.
Open recent pull requests and test runs.
Point to incident reviews and improvements.
All of that is:
Consistent.
Current.
Tied to a clear control owner.

If you can do that from one environment, rather than by chasing through personal folders and separate tools, you are already close to what good practice under A.8.28 looks like in daily operations.

What secure‑coding foundations matter most for a licenced gambling business?

The list of possible controls is long, but licenced operators typically earn the most trust-and the fewest findings-by getting four foundations right: practical rules, capable people, embedded workflow, and traceable proof. A.8.28 effectively asks whether those four are present wherever you could unintentionally change fairness or money.

How should you frame secure‑coding rules so they help rather than hinder?

1. Make standards match your actual technology and gambling risks

Your secure‑coding standard should feel like a handbook for your real stack, not a copy of a generic checklist. That means it:

Names the technologies you actually use:
Languages, frameworks, and build systems.
Data stores, message buses, and deployment patterns.
Identifies gambling‑specific concerns, such as:
RNG selection and use.
Payout, cashback, and bonus calculations.
Limits, exposure caps, and voiding rules.
Client–server and service–service trust boundaries.

Teams then see the standard as a genuine guide for the platform you run, not as a theoretical requirement.

2. Treat secure coding as a skill, not just a document

You make it easier for people to do the right thing by design:

Onboarding for engineers, QA, product owners, and architects includes:
Secure‑coding fundamentals.
Concrete gambling scenarios (for example, predictable seeds, duplicated pricing logic).
Changes in standards, regulations, or incident patterns trigger:
Short, focused refreshers.
Updated examples in code templates and documentation.
Tools keep expectations close to the work:
Snippets and patterns in repositories.
Checklists in pull‑request templates.
Links from warnings in static analysis tools back to your internal guidance.

That combination shows auditors that A.8.28 is grounded in competence, not just awareness.

3. Embed secure coding into how work flows, not as an add‑on

For systems that influence fairness, balances, or licence conditions, your definition of “done” usually includes:

A lightweight design or risk step that:
Captures where randomness, pricing, and money flows are changing.
Points to relevant parts of your standard.
At least one review by someone with the right risk context.
Tests that deliberately exercise:
Source of truth (server vs client).
Boundary conditions (limits, odds extremes, large accumulators).
Abuse cases identified by risk or compliance teams.

Less‑critical areas still follow core secure‑coding habits, but without the same depth or ceremony.

4. Keep an evidence chain you can revisit

A regulator or ISO 27001 auditor is unlikely to be impressed if the only proof you can show is a PDF standard and a training slide deck. They will look for:

A handful of real examples where:
Secure‑coding expectations shaped how work was done.
Issues were found and fixed before they hit production.
Lessons from incidents or near misses changed future behaviour.

This is where an ISMS or Annex L‑aligned integrated management system helps. Use it to link A.8.28 to risks, project work, training, test outputs, and incident reviews so the same storey is available across teams and audits without starting again from nothing.

How can you design and seed RNGs so they stand up to regulatory and ISO 27001 scrutiny?

For gambling platforms, RNGs are more than a technical detail-they are part of the fairness promise that underpins your licence. A.8.28 expects secure coding to cover how randomness is chosen, seeded, protected, tested, and changed, not just whether a lab has once signed off your implementation.

What practical steps put RNG secure coding on a solid footing?

1. Decide which RNG implementations are allowed-and where

Start by being explicit about which RNG building blocks your platform may use:

For any outcome that affects money or game fairness, you select:
Modern cryptographically secure RNGs or deterministic random bit generators (DRBGs) from trusted libraries or platform APIs.
Approved call patterns, including how seeds and nonces are supplied.
For cosmetic randomness only (animations, visual effects), you document:
Whether simpler RNGs are tolerated.
The boundaries where predictability would not influence payouts.

Everything else-home‑grown functions, timestamp‑only seeds, debug shortcuts-is clearly banned from production code that influences outcomes or exposure.

2. Document a seeding and reseeding model people actually follow

Randomness is often weakened not by the RNG itself, but by how it is seeded:

Your standard explains:
Approved entropy sources (operating system, hardware).
How seeds are combined and protected.
How reseeding behaves in long‑running and high‑volume services.
You make it explicit that seeds must never depend on:
Readable timestamps.
Simple counters.
User identifiers or similar low‑entropy inputs.

This removes guesswork for developers and gives auditors a clear storey to follow.

3. Protect configuration, state, and debug behaviours

Even a well‑chosen RNG can be undermined by careless state handling:

Debug modes that make outcomes predictable are:
Disabled entirely in production.
Carefully controlled and monitored in test or staging environments.
Logs and diagnostics:
Avoid revealing seeds or internal RNG state.
Provide enough detail for troubleshooting without handing an attacker a shortcut.
Access to entropy devices, configuration files, and deployment parameters:
Is restricted on a need‑to‑know basis.
Generates audit trails that can be reviewed after incidents.

Those measures typically intersect with other Annex A controls on access management and logging, but the reasoning sits squarely within A.8.28’s expectation of safe coding in high‑risk areas.

4. Combine lab certification with internal secure‑coding practice

External testing by recognised labs is a key part of gambling assurance, but it does not replace secure coding:

Lab reports are:
Tied to specific code revisions and configuration states.
Stored in a way that lets you demonstrate continuity over time.
Your teams use those reports as:
Inputs to internal threat models.
Triggers for new tests or extra checks in CI/CD.
Reference points when updating RNG‑related standards.

By recording that chain-from the standard through code, lab work, and runtime behaviour-in a structured system, you position RNG design as an ongoing, testable control rather than a one‑off certification exercise.

How should you code gambling clients when every device could be hostile?

On a gambling platform, you never fully control the devices or networks where your clients run. Browsers can be scripted, mobile apps can be modified, and desktop clients can be reverse‑engineered. A.8.28 pushes you to assume compromise and still prevent players from quietly changing odds, balances, or settlement.

Which patterns keep authority in the right place and reduce quiet abuse?

1. Keep all financial and fairness decisions on the server

A simple design rule dramatically reduces risk:

The server decides:
When a bet is accepted or rejected.
How odds are applied.
How and when settlements happen.
When promotions and bonuses apply.
The client:
Collects inputs.
Displays states.
Never changes balances or outcomes on its own.

Even if latency pressures you to show preview values locally, you treat those as hints and recompute authoritative values on the server before committing anything that affects money or fairness.

2. Assume every client input can be manipulated

Regardless of channel, your code should act as if:

Requests can be:
Replayed and reordered.
Modified on the wire.
Driven at unnatural speed.
So you:
Validate sizes, identifiers, and timing on the server.
Check account status, limits, and market state for each sensitive action.
Detect and block sequences that do not match a normal bet lifecycle.

Those checks are part of secure coding just as much as they are part of fraud detection.

3. Protect transport, sessions, and instal/update paths

Good hygiene still matters:

You apply:
Current TLS configurations.
Sensible session lifetimes.
Re‑authentication for withdrawals and high‑value actions.
For installable clients:
Binaries and updates are signed and validated.
Distribution channels are controlled.
Integrity checks run at startup or during updates where the value at risk justifies it.

The goal is not absolute resistance to local attacks, but to keep any compromise local and visible rather than systemic and silent.

4. Build a minimal, focused set of signals into client interactions

Client and server code can quietly help your monitoring and risk teams by emitting:

Signals around:
Unusual device or network behaviour.
Abnormal click patterns or latencies.
Repeated failed attempts to exploit edge cases.
With clear retention and access rules so that:
Disputes can be investigated.
Unnecessary personal data is not held without purpose.

When those patterns, tests, and signals are tied back to A.8.28 in your management system, you can show that secure coding on clients is part of a wider, intentional defence posture-not just an aspiration.

How does ISO 27001 A.8.28 influence the way you build and change betting engines?

Betting engines encode your commercial strategy, risk appetite, and regulatory duties. Under A.8.28, the code and configuration behind those engines should be understandable, reviewable, and explainable long after the original team has moved on. Your goal is not just that they work, but that you can stand over them when questioned.

What makes a betting engine implementation robust and explainable?

1. Maintain clear models for how bets behave

You keep up‑to‑date artefacts-often simple diagrams or narratives-that answer:

Where odds come from and how they are adjusted:
Feeds, models, manual inputs, or combinations.
How a bet moves:
From request through acceptance to settlement, refund, or void.
What special conditions apply:
Suspensions.
Postponements and cancellations.
Promotions and complex combinations.

Engineers and product teams then use those models as the reference point when extending or changing functionality, instead of relying on assumptions.

2. Centralise critical logic rather than copying it

To avoid subtle, channel‑specific errors:

Pricing, rule evaluation, and settlement logic:
Live in shared services or libraries.
Are reused by all relevant front ends and channels.
When business teams request custom behaviour for a campaign or region, you:
Implement variation in the shared engine where possible.
Avoid duplicating critical logic into local code paths that are easy to forget and hard to test.

That discipline supports both consistency and efficiency when you later need to test or demonstrate behaviour.

3. Apply strong controls around who can change what

Because betting engines can move real money quickly, code and configuration that influence exposure or fairness deserve tighter treatment:

Interfaces for:
Changing odds or limits.
Adjusting settlement behaviour.
Overriding results.
Are:
Behind role‑based access controls.
Logged in detail.
Changed through structured requests with appropriate approvals.

Secure coding here means not just how you write functions, but how you design, protect, and validate the paths that adjust engine behaviour in production.

4. Treat transaction integrity as a coding requirement

Your implementation should make it straightforward to reconstruct what happened when a dispute arises:

Important lifecycle events, such as bet placement, acceptance, and settlement, are:
Recorded in append‑only or event‑sourced structures.
Retained for periods that align with licence and dispute‑handling requirements.
Where proportionate, you:
Hash or sign batches or streams.
Verify integrity during investigations.

Those choices help regulators see that fairness is not only enforced at runtime, but can be demonstrated over time.

Linking these design decisions, standards, reviews, and event‑logging expectations back to A.8.28 in your ISMS makes it much easier to show how your betting engines were built and evolved safely, rather than asking stakeholders to trust an undocumented black box.

What evidence should you prepare for A.8.28 that also satisfies gambling regulators?

For high‑risk systems, ISO 27001 auditors and gambling regulators now expect to see an evidence chain that connects secure‑coding expectations to everyday practice. For A.8.28, the strongest stories show how those expectations steer work on real components that influence fairness, balances, and reporting.

Which types of artefacts tell a convincing, joined‑up storey?

1. Practical secure‑coding standards and pattern libraries

You maintain:

A concise, current secure‑coding standard that:
Names your stacks and deployment patterns.
Addresses gambling‑specific risks: RNGs, limits, bonus logic, settlement rules, reporting.
Short pattern guides with:
“Preferred” examples (for example, correct RNG usage and safe payoff logic).
“Discouraged” or prohibited examples that have caused issues elsewhere.

Those documents are referenced in tickets, reviews, and training material.

2. Training and competence records

For relevant roles-developers, testers, architects, DevOps, risk and fraud teams-you can show:

Completion of secure‑coding and gambling‑risk training.
Dates of last refresh.
How new joiners are introduced to your secure‑coding standard and review processes.

That evidence links Annex A.7 (people controls) to A.8.28 (technical controls) in a way auditors can quickly follow.

3. Code‑review and change histories on key systems

For a sample of critical components (RNGs, betting engines, wallets, settlement systems), you retain:

Pull‑request or change records that:
Flag security and gambling impacts.
Document concerns raised and fixes applied before deployment.
Links from changes to:
Risk entries.
Design documents.
Incident reports where relevant.

This shows that secure coding influences real decisions instead of being treated as a checkbox.

4. Tooling outputs and follow‑through records

You treat tools as part of the control, not a box‑ticking exercise:

Static and dynamic analysis, fuzzing, or fairness checks:
Are run on appropriate systems.
Have outputs stored in a way that lets you track trends over time.
For significant findings, you keep:
Triage notes.
Decisions (accepted, mitigated, fixed).
Links to follow‑up work.

Auditors often focus less on the presence of findings and more on the quality of your response.

5. Independent assessments tied back to your code and configuration

Gambling regulators tend to place heavy weight on:

RNG certifications and fairness reports from recognised labs.
Penetration tests and red‑team exercises covering:
Game clients and APIs.
Wallet and settlement flows.
Admin and risk tooling.

For A.8.28, the key is that those reports are:

Clearly linked to particular code and configuration versions.
Stored and referenced inside your management system alongside internal standards and test results.
Accompanied by visible remediation where issues were found.

6. Incident, near‑miss, and improvement logs

You round out the storey by showing how secure coding improves over time:

Incidents and near misses involving fairness, exposure, or balances:
Are described in enough detail to see technical contributing factors.
Lead to changes in standards, checklists, tooling, or review rules where appropriate.
Those actions are:
Tracked as work.
Checked later for effectiveness.

When all of these artefacts live in a structured environment instead of scattered across tools and teams, it becomes much easier to convince auditors, regulators, and internal stakeholders that secure coding is embedded, not aspirational. Pulling A.8.28 into the same view as risks, Annex A controls, projects, and audit programmes also makes it simpler to grow from an ISMS into a wider Annex L‑aligned integrated management system over time, without losing the thread of how your code protects players, money, and your licence.

ISO 27001 A.8.28 – Secure Coding for Rng, Game Clients & Betting Engines