Configuration Drift for an Online Casino: A Post-Go-Live Hardening Re-Check Checklist

Q: What is configuration drift?

Configuration drift is the gap that opens between a system's approved secure baseline and its actual state over time. It comes from ordinary operations: emergency changes, new hosts built from old templates, temporary access that is never removed, and manual fixes made outside the normal process.

Q: How is configuration drift detected?

By comparing live systems with the written baseline and listing every difference. The comparison can be a scheduled scan against a named benchmark, a policy-as-code check on cloud accounts, or a diff of host configuration against a golden image. Each difference is either reverted or recorded as an approved exception.

Q: How often should an online casino re-check its hardening baseline?

On a calendar and on events. A calendar re-check catches slow decay; event-driven re-checks catch the moments that cause drift, such as a new environment for a game launch, an emergency firewall change, or a provider integration. Set the calendar interval in your own policy, because ISO/IEC 27001 names no fixed interval.

Q: Is configuration drift the same as a missing patch?

No. A missing patch is an out-of-date software version. Drift is a changed setting, such as a re-enabled service, a new administrator or an opened port. A patch report will not show it, and a vulnerability scan only finds part of it.

Q: What does an auditor want to see for configuration monitoring?

A named baseline, dated comparison results against live systems, and an exceptions register with owners and review dates. ISO/IEC 27001:2022 Annex A 8.9 expects configurations to be established, documented, implemented, monitored and reviewed. For PCI DSS, an assessor will compare running systems against your own documented configuration standard.

The short answer

Configuration drift is the distance between the baseline you approved and what your systems are actually doing now, and for an online casino it opens at predictable moments: a game launch, an emergency firewall change, a new provider integration, an administrator added for a migration. The fix is not a bigger annual audit. It is a short re-check tied to each of those events, run against the same named baseline you used to harden the estate, with every difference either reverted or written into an exceptions register.

Who this is for

This is for the head of infrastructure, platform lead or CISO at a licensed online casino whose systems were hardened once, at go-live or before an audit, and who has no routine way to know whether that state still holds. It assumes a baseline already exists. If you are choosing what to harden first, read cloud and server hardening for an online casino. If you are unsure whether an audit line means hardening or patching, read hardening vs patching for an online casino.

Why a clean baseline does not stay clean

A baseline is a state, and operations move state. Casino estates change faster than most because promotions, tournaments and provider integrations each create short-lived infrastructure with a long tail. Patching survives this because the patch pipeline is automatic. Configuration does not, because it depends on someone remembering to apply the baseline to the new thing and to put back whatever the urgent change took away.

Drift is rarely negligence. It is a firewall rule opened at 02:00 to restore a payment route, a template that predates the baseline, a temporary administrator whose ticket was closed without a revocation. Each is reasonable when it happens. The risk is that nothing marks it afterwards, and the next time anyone compares the system with the baseline is the next audit.

Triggers and the re-check each one needs

Trigger	What typically drifts	Re-check to run
New cloud account or environment (game launch, tournament, new market)	Built from an old template, baseline controls missing	Run the baseline benchmark against the new account before it takes traffic
New hosts or images	Default accounts, unneeded services, management ports	Compare to the golden image or build script; confirm hosts came from the current one
Emergency change (firewall, WAF, routing)	Rules left open, temporary exceptions made permanent	Review the change record; confirm the change was reverted or approved as an exception
Provider or payment integration	New service accounts, API keys, inbound allow-lists	List new identities and network paths; confirm scope and owner
Administrator onboarding or offboarding	Roles granted and not removed, MFA gaps	Reconcile privileged roles with the current staff and role list
Major platform or OS upgrade	Settings reset to vendor defaults	Re-apply and re-verify the baseline for that system type
Calendar interval	Slow, unattributed decay	Full comparison against the named baseline for every in-scope system type

The first five are event-driven and usually quick, because they inspect one thing. The last is the full sweep, and it exists to catch drift that no event announced.

The re-check, step by step

Fix the reference. Name the baseline for each system type by version: operating system image, database, container host, cloud account. You cannot measure drift against "best practice".
Scope the comparison. List the systems the baseline applies to. A new host missing from the list is the most common gap, which is why the inventory comes first.
Run the comparison. Use whatever produces a difference list rather than a verdict: a benchmark scan, a policy-as-code check, a configuration diff. Record the date and the tool version.
Triage each difference. Revert it, or record it as an exception with an owner, a reason and a review date. Nothing stays unexplained.
Close the loop with the change record. For each difference, find the change that caused it. If there is none, treat it as an unauthorised change and escalate.
Store the result. Keep the dated comparison and the updated register. A series of dated results is evidence; a single report is a snapshot.

What counts as an exception, and what does not

An exception is a deliberate, approved departure from the baseline: a legacy system that cannot take a setting, with a compensating control and a review date. A difference nobody can explain is not an exception; it is a finding. The register is only useful if it stays short and current. If every difference ends up there, it records drift rather than managing it.

What the standards ask for

ISO/IEC 27001:2022 Annex A 8.9 expects configurations, including security configurations, to be established, documented, implemented, monitored and reviewed. The word monitored is where drift detection belongs. The standard sets no fixed interval, so the cadence is yours to define in policy, and an auditor will test you against what you wrote.

PCI DSS 4.0.1 Requirement 2 asks for documented configuration standards for in-scope system components that are applied and kept current. An assessor will compare running systems against your own standard, so a written baseline that live systems no longer match is a gap even when the document is good. The standard does not name drift detection as such; a regular comparison is simply the practical way to show the standard is still being met. Confirm the exact wording with your assessor.

Limitations

This is a checklist for re-verifying an existing baseline, not a build guide, and it quotes no market prices, durations or AnySec-original figures. A configuration comparison finds differences from a baseline; it does not find unknown vulnerabilities, so it complements rather than replaces a vulnerability assessment. It does not cover jurisdiction-specific gambling-licence technical standards, which may impose their own monitoring requirements.

What to do next

Pick the trigger from the table that happened most recently in your estate and run its re-check this week. If the answer to "what is our baseline?" is not a named version per system type, that is the real gap: request a baseline review for your casino estate and tell us the system types and cloud accounts in scope. The Security Hardening page describes how an engagement runs and what you receive.

Frequently asked questions

What is configuration drift? The gap between a system's approved secure baseline and its actual state, caused by emergency changes, old templates and access that is never removed.

How is configuration drift detected? By comparing live systems with the written baseline and reverting or recording every difference.

How often should an online casino re-check its hardening baseline? On a calendar and on events such as launches, emergency changes and integrations. ISO/IEC 27001 names no fixed interval.

Is configuration drift the same as a missing patch? No. Drift is a changed setting; a patch report will not show it.

What does an auditor want to see for configuration monitoring? A named baseline, dated comparison results, and an exceptions register with owners and review dates.

Sources and review

This article describes ISO/IEC 27001:2022 Annex A 8.9 and PCI DSS 4.0.1 Requirement 2 in general terms from the published standards' structure and secondary summaries; it cites no statistics, prices or AnySec-original numbers, case results or SLA figures. Author: AnySec Engineering. Published 2026-10-10; last reviewed 2026-10-10.