In Spain, the object that reaches the regulator is not a game. It is a technical system described as an inventory of software components, each identified by manufacturer, product name and version, with the components classified as critical carrying their own digital fingerprint. The Dirección General de Ordenación del Juego (DGOJ) homologates that system, and the game is certified inside it. A studio that plans the submission as a game build plus a rules document will produce a dossier that describes the wrong object.
This article sets out what the Spanish framework actually requires of the dossier, why the component inventory is the organising document rather than an appendix, and what the production brief has to settle so that the inventory stays true after launch. It follows the DGOJ’s published homologation process and the model for the definitive certification report in the Resolución de 6 de octubre de 2014 (BOE-A-2014-10303, consolidated text last updated 3 November 2022).
The two-stage sequence, and why the second stage is the harder one
Spanish homologation runs in two distinct stages with different evidence in each. The first stage is the prior control that accompanies a licence application. It is fundamentally documentary: the applicant submits a technical project together with a preliminary certification report on compliance with the technical requirements. An applicant for a general licence also submits a certification report on its internal control system. At this stage the regulator is assessing the design of the system and the credibility of the evidence plan, not the behaviour of a live production environment.
The second stage begins after the licence is granted. General licences are conditional and singular licences are provisional until definitive homologation is obtained, and definitive homologation must be achieved within six months of the licence. The operator then submits definitive certification reports on the technical system actually used. Those reports must be filed within four months of the notification of the licence grant, a deadline the resolution describes as not extendable. Only after the DGOJ evaluates the definitive report favourably does the system become definitively homologated.
The practical consequence for a studio is that the preliminary report is a promise about the system and the definitive report is proof of it. A dossier written to satisfy the preliminary stage, without a plan for producing the definitive evidence from the real production system, leaves the operator holding a conditional or provisional licence with a four-month clock running. The sequencing belongs in the commercial plan, not in the week before submission.
The report is an inventory document
Anexo III of the resolution sets the minimum structure and content of the definitive functionality certification report. It runs to nine sections: identification of the certification; description of the object of certification; an executive summary; detail of compliance with each technical requirement; detail of specific analyses; detail of integration tests; the place, equipment and dates of the certification work; a description of any test environments other than the environment the operator actually uses; and a description of the digital support accompanying the report.
The second section is the one that changes how a studio should think about the build. The “object of certification” is the scope of the technical system, and the resolution requires it to identify the software elements used in the system, with the manufacturer, product name and version of each. Two elements must appear in every case: the capturador and the almacén — the internal control system’s capturer and store. The report must also list the components qualified as critical together with their fingerprints, identify the data centres where the system is installed, and list the certified access channels. For a singular licence it must further identify the certified websites and trade names, the operator’s role as B2C, B2B or both — including whether a B2B operator acts as a co-organiser of games — the certified game offer with its variants, and the access technologies certified, such as web access, downloadable clients or native mobile applications.
That list is not administrative decoration. It defines what a certification body will assess and what the operator must keep true. A game build that embeds an unlisted third-party component, or that changes a version number without updating the inventory, is a system that no longer matches its certification. The inventory has to be produced from the same source of truth as the build, or it becomes a document that is correct only on the day it is signed.
The critical-component list decides what must be fingerprinted
The resolution’s requirements for the information-security area include a specific test: the certification entity must verify that the organisation has identified the critical components of its technical system and that the list includes a defined set of categories. Those categories are the user registration system, the gaming account, payment processing, the components that transmit or process random numbers and the integration of random-number results into game logic, the components that store, manipulate or transmit sensitive customer information, the components that store the instantaneous game state, the connections with the DGOJ, the internal control system’s capturer and store, the access points and communications to and from those critical components, and the communication networks that carry sensitive participant information.
For a slot game, several of these categories sit inside the game build or immediately around it: the RNG integration, the game-state store used to resume an interrupted round, the access points, and the communication path between the game client and the game server. A studio that treats certification as a maths review will not have classified those components, will not have fingerprints for them, and will not be able to show the certification entity that the list is complete. The brief should assign each category to an owner and record where its fingerprint is produced.
The resolution also permits an organisation holding a current ISO 27001 certification to satisfy the information-security area requirement, with “ISO 27001” recorded in the observations. That is useful for an operator with an established management system, but it does not remove the need to identify the game-specific critical components or to fingerprint them.
The RNG analysis is a structured evidence set
Where a singular licence uses a random number generator, the definitive report must include an RNG analysis with defined fields: the manufacturer of the generator; the product name and version; the digital fingerprint of the binary; whether it is hardware or software; whether it is random or pseudo-random, and for a random source the physical phenomenon it relies on; whether the generator instance is shared with other games and, if so, which; the algorithm and, for software, the libraries or operating-system calls it relies on; whether there is a reseeding procedure; the bit length of the space of distinct random numbers; and the list of statistical tests performed.
This is more specific than “describe your RNG”. It is a request for the generator’s identity and provenance in the same form as the rest of the component inventory. A studio using a licensed third-party RNG should obtain those fields from the supplier as part of procurement, not reconstruct them during certification. A studio building its own generator should record them in the technical design from the first prototype, because the bit length of the space and the reseeding behaviour are design properties, not documentation properties.
RTP publication and the game-logic analysis
For games with a return percentage, the report records the published return-to-player percentage for each game and the location where that percentage is published. The percentage is therefore not only a maths figure; it is a published statement whose location is part of the certification evidence. A change to the published figure or to the page where it appears is a change to the certified representation, and the brief should record who owns that page and how it is updated.
The game-logic analysis covers the particular rules of the game, whether the operator uses a bespoke or product risk-management system for counterparty bets, whether configuration changes to that system are audited, whether changes made by operator staff to bets are audited, the list of random events and whether they are pre-drawn, and whether configuration changes to the game logic are audited. For a slot game, the random-event list is where the mechanic’s state model becomes visible to the certifier: which events draw from the generator, and whether outcomes are determined before the round or during it. The casino game rules specification guide covers how to write the rules document that supports this analysis; the Spanish report adds the requirement to enumerate the random events and the audit trail around configuration.
Integration tests and environment parity
The report must detail the integration tests performed, graded by requirement area against the tests in Anexo VI, with additional tests named beginning with “X”. It must also describe the place, equipment and dates of the certification work, and describe any environment used for testing that differs from the environment the operator actually uses in production.
The resolution is explicit about what a different environment requires. For certifications carried out in the context of a substantial change, integration tests may be performed in an environment other than the production system. Where that happens, the certification entity must certify, on its own responsibility, that the results obtained in the test environment can be extrapolated to the production system, having analysed whether any differences between the two affect the quality of the test result. For a studio, that means the test environment must be documented as a controlled replica, not an ad hoc staging server, and the differences must be known and recorded before the tests run.
Change management continues after homologation
The obligation that most often surprises studios is the one that starts after homologation. The operator must have a documented change-management procedure covering changes to the equipment and components of the technical system actually used. The operator must send the DGOJ a quarterly report describing the changes made in the period and keeping the system description current. The DGOJ may require that quarterly report to include a digital fingerprint of the binaries.
Substantial modifications affecting critical components require prior authorisation before they go into production, following submission of the corresponding certification report. The DGOJ resolves the authorisation within one month of receiving the application. If the DGOJ considers a change made to a critical component to be substantial, it can require the operator to homologate the change and can require the change to be withdrawn until the homologation is obtained. For extraordinary security emergencies that are duly evidenced and notified to the DGOJ, an operator may introduce substantial changes to critical components and request authorisation afterwards, submitting a report that evidences the exceptional circumstances and the security risk.
A studio that ships a live-service game into Spain is therefore not finished at homologation. Every patch that touches a critical component has to pass through a classification decision, and the classification has to be defensible. The brief should define which changes are routine, which are substantial, and who makes that call — and it should do so before the first post-launch patch, not after the regulator asks why a binary changed.
What the production brief must record
The Spanish dossier is manageable when the brief treats it as a configuration and evidence plan. Six decisions belong in the brief before development starts.
- The component inventory and its owner. A named list of software elements with manufacturer, product name and version, including third-party libraries and the internal control system’s capturer and store, with an owner responsible for keeping it current.
- The critical-component map. Which components fall into each category the resolution requires, where each fingerprint is produced, and how a version change updates both the fingerprint and the inventory.
- The provider homologation status. Spanish homologation attaches to the operator’s system, and the resolution describes that system as the set of software providers — platform software, game software, aggregator software and warehouse software — previously homologated or authorised through homologation or substantial-change procedures. A studio supplying a game to a Spanish licensee should establish, before contracting, whether it is already a homologated software provider or whether its integration requires a substantial-change authorisation.
- The two-stage evidence plan. What the preliminary report will assert, what the definitive report will prove, which production system will produce the definitive evidence, and who is responsible for filing within the four-month window.
- The change-classification rule. Which changes count as substantial for each critical component, who approves the classification, and how the quarterly report is assembled from build records rather than reconstructed at quarter end.
- The environment-parity record. How the test environment is kept equivalent to production, what differences are accepted, and who certifies the extrapolation when the environments differ.
None of these decisions requires a different game design. They change what the studio records while building, which is why they belong in the brief rather than in the certification phase. A publisher or studio preparing a Spanish submission can request a project quote with the intended licence type and market scope.
Frequently asked questions
Does the DGOJ certify the game or the operator’s technical system?
It homologates the operator’s technical system, and the game is certified within that system. The definitive functionality report describes the scope of the system, including the software elements and their versions, the critical components and their fingerprints, the data centres, the access channels, the certified game offer and the operator’s role. A game supplier’s software becomes part of that described system, which is why the provider’s homologation status matters before contracting.
What happens between the preliminary report and definitive homologation?
The preliminary certification report accompanies the licence application and is assessed documentally. After the licence is granted — conditionally for a general licence and provisionally for a singular licence — the operator must file definitive certification reports within four months of the notification, and obtain definitive homologation within six months. The definitive report covers the system actually in production, so the evidence has to come from the live environment rather than from the design documents.
Is a change to the game after launch automatically a new certification?
Not automatically, but it may require prior authorisation. A substantial modification affecting a critical component needs authorisation before production, supported by a certification report, and the DGOJ responds within one month. The operator also files a quarterly change report. If the DGOJ judges a change to a critical component substantial, it can require homologation and can require withdrawal until that homologation is obtained. The classification rule should be agreed before the first patch.
Can a test environment be used instead of the production system?
The resolution allows integration tests in an environment other than production in the context of a substantial change, but the certification entity must certify that the results are extrapolable to the production system and must analyse whether differences between the environments affect the test result. The dossier therefore has to describe the test environment and its known differences, not simply name it.
