A backup schedule reports that copies were produced. It does not report that the platform can be brought back. For an operator, the difference between those two claims is a dated restore drill run against a target the live system never touches, with its own evidence.
The scope of that drill is wider than one database. Recovery has to answer for player accounts, the wallet ledger, game round and bet history, bonus liability, jackpot contribution state, the configuration that decides how each of those behaves, and the analytics an operator reports from. Each has a different tolerance for lost history, and a single “database restored” line does not distinguish them.
Separate “copies exist” from “the platform can be restored”
NIST’s contingency planning guidance frames the work as a plan that has to be developed, exercised and maintained rather than a storage configuration. SP 800-34 Rev. 1 describes contingency planning as developing “the purpose, process, and format of information system contingency planning”, and the earlier edition of the same guide sets out a seven-step process whose last two steps are “plan testing/training/exercises, and plan maintenance”. SP 800-184, published in December 2016, provides “tactical and strategic guidance regarding the planning, playbook developing, testing, and improvement of recovery planning”. See the NIST contingency planning guide and the cybersecurity event recovery guide for the wording and scope.
Both are general information-system guidance. Neither defines a recovery objective for a gambling platform, certifies a deployment, or replaces the licensee’s own acceptance criteria. What they establish for an engineering team is narrower and still useful: the test is part of the control, and a restore that was never exercised is an untested assumption.
Decide the recovery scope before the drill runs
“Restore the platform” is not a testable statement. A drill becomes checkable when each data class has its own recovery question and its expected evidence:
| Data class | Recovery question the drill answers | Evidence the drill should keep |
|---|---|---|
| Player account and verification records | Are account records complete and internally consistent at the recovery target? | Record counts and identity-field checks against the source, plus the sampled records a reviewer can re-read. |
| Wallet ledger and balances | Do reconstructed balances equal the reconciled position before the incident? | The recomputation query, its result, and the reconciliation it was compared with. |
| Game round, bet and settlement history | Are round outcomes and their wallet postings present, linked and unduplicated? | Counts per game and provider, linkage checks, and the duplicate check for rounds replayed after the target. |
| Bonus and promotion liability | Are active promotions and their outstanding liability represented as they were? | The list of active promotions with their liability at the target, and where the value came from. |
| Jackpot and other accrual state | Is contribution state recoverable with the records that justify it? | The accrual figures restored and the rule or configuration version that produced them. |
| Configuration, keys and integration credentials | Can the restored environment talk to the services it depends on without editing production material into it? | The versioned configuration identifier and how credentials were supplied for the drill. |
| Derived analytics and reporting extracts | Can reporting be rebuilt from recovered sources rather than from a partial copy? | The rebuild command, its output, and any period that cannot be rebuilt. |
Do not assume every row belongs in the same recovery objective. A ledger restored to a slightly earlier point is a financial correction; a reporting extract restored to the same point is not.
Restore into an isolated target, never over the live system
A restore is a write. Run it into a separate environment, and record what the source snapshot was. Point-in-time recovery typically combines a base backup with archived write-ahead log: the PostgreSQL continuous archiving documentation describes replaying an archived log forward from a base backup and names the stopping point the “recovery target”, which can be given as a date and time, a named restore point or a completed transaction ID.
That documentation also explains why the branch matters. A point-in-time recovery creates a new timeline, and recovered history does not overwrite the write-ahead log generated before it; the same page records that you cannot recover into a timeline that branched off before the base backup was taken. Practical consequence for a drill record: the snapshot identity, the chosen recovery target and the resulting timeline belong in the evidence, because “we restored the database” is ambiguous once a platform has been recovered more than once.
The mechanism is engine-specific and this page describes one engine’s behaviour rather than every platform’s. The general rule is portable: know which artefact defines the point you restored to, and keep it.
Verify the ledger arithmetic, not the row count
A restore can return the expected number of rows and the wrong balances. Row counts survive a restore that a player would dispute, because a missing offsetting posting and an extra one cancel out in a total.
Recompute balances from the restored postings and compare that result with the reconciled position that preceded the incident rather than with the value in the restored balance column — otherwise a corrupted balance table is compared with itself. Then check the joins that make a ledger usable: every settled round has its wallet postings, no posting exists for a round that is absent, and rounds accepted after the recovery target are not counted twice if the drill replays them. The wallet reconciliation requirements guide describes the reconciliation controls those comparisons depend on.
Treat a point-in-time restore of a ledger as a one-way door
Recovering to a moment before the incident also rewinds everything that happened after that moment. For a ledger, that is a business decision, not a restore setting: activity between the recovery target and the incident has to be reapplied, voided or settled another way, and someone accountable has to authorise which.
Decide before the drill, not during an incident, who may choose the recovery target, how post-target bank, wallet and game activity is classified, what the player sees in their transaction history afterwards, and how the correction is recorded. An operator that has not answered those questions has a backup, not a recovery capability.
Record the drill as dated evidence
A test that leaves no artefact is indistinguishable from a test that was skipped. A minimal record holds the source backup identity and its checksum, the recovery target, the isolated environment used, the measured duration against the objective the platform claims, the verification queries with their results, every exception with its owner, the date, and the reviewer. Keep it where the security logging and audit evidence guide would keep a comparable investigation record, and keep the query text rather than a screenshot of a green dashboard.
Naming a regulator’s expectations is not the same as meeting them. As an example of the direction such evidence travels, the UK Gambling Commission states on its remote gambling and software technical standards page that remote and gambling software licence holders must comply with the RTS and with “requirements relating to the timing and procedures for testing” under licence condition 2.3.1, that the standards include security requirements drawn from ISO/IEC 27001:2013, and that the published tree includes RTS 9 progressive jackpot systems, RTS 10 interrupted gambling and RTS 16 use of third party software. This page is a pointer to those published standards, not an interpretation of them: whether any specific requirement applies to a given platform is a question for the licensee, its assessor and the regulator.
Stop at what the restore proves
A completed restore proves that the data could be brought back on that date, to that target, in that environment. It does not prove the service resumed within any particular time, that downstream providers reconnected correctly, or that the platform met an obligation. Those are separate exercises and should be reported separately.
Keep the restored environment available long enough to answer the questions the drill created, and destroy it deliberately afterwards with the record of what was in it. The incident response plan guide covers the phase in which a real recovery decision would be made; the data residency and cross-border transfer guide covers why the location of the restore target is itself a question rather than a default.
