TECHNICAL REPORT ON THE CHANGE MANAGEMENT PROCESS IN THE GAME TECHNICAL SYSTEM AND APPROVAL PROCESS FOR SUBSTANTIAL CHANGES ON CRITICAL COMPONENTS

Transcription

1 Warning: Translation may be imprecise and inaccurate. While reasonable efforts are made to provide a translation, no liability and no responsibility are assumed by Dirección General de Ordenación del Juego for any errors, omissions, or ambiguities in the translation or other information provided. In case of any discrepancies between the Spanish original text and the English translation, the Spanish original text shall govern and prevail, whose title is NOTA TÉCNICA Y OPERATIVA SOBRE LA GESTIÓN DE CAMBIOS DEL SISTEMA TÉCNICO DE JUEGO Y LA AUTORIZACIÓN DE CAMBIOS SUSTANCIALES EN COMPONENTES CRÍTICOS. TECHNICAL REPORT ON THE CHANGE MANAGEMENT PROCESS IN THE GAME TECHNICAL SYSTEM AND APPROVAL PROCESS FOR SUBSTANTIAL CHANGES ON CRITICAL COMPONENTS 1. Aim of the document In response to the numerous inquiries received in regard to the change management process and the approval process of substantial changes, it has been decided to publish this report. The aim of this report is to provide further information, in addition to what is already established in the Spanish Gambling Act (Ley 13/2011, de 27 de mayo, de regulación del juego) and its further development on this area. This report provides guidelines for the compliance to the obligations related to the change management and approval of substantial changes processes, the associated procedures, the documentation associated with each procedure, and the assessment for consideration "substantial" change on a critical component. The document is subject to change. New versions will be published in the website of the Dirección General de Ordenación del Juego (DGOJ). There have been identified three different procedures: Applying for authorization for substantial change Applying for authorization for substantial change in case of extraordinary emergency Sending quarterly changes report 2. Version control Date Version Description 01/04/ Initial version. 1

2 3. Index 1. AIM OF THE DOCUMENT VERSION CONTROL INDEX POLICY CONTEXT CHANGE MANAGEMENT PROCESS AND OBLIGATIONS WITH QUARTERLY CHANGES REPORT OPERATORS SERVICE CHANGE MANAGEMENT PROCESS IN CASE OF EXTRAORDINARY SECURITY EMERGENCY AND OBLIGATIONS WITH ANNEX I. GUIDELINES TO ASSESS THE SUBSTANTIAL NATURE OF A CHANGE IN THE TECHNICAL SYSTEM ANNEX II. CONSIDERATIONS ON THE REPORTS FOR CERTIFICATION OF A SUBSTANTIAL CHANGE

3 4. Policy context Article 16 of the Spanish Gambling Act (Ley 13/2011, de 27 de mayo, de regulación del juego) establishes the approval process of game technical systems. Its further development establishes obligations related to the change management. Article 8 of the Royal Decree 1613/2011 (Real decreto 1613/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 de mayo), refers to the need to approve any substantial changes which affect any critical components, considering critical as any elements related to the random number generator, the user registration and account set, the internal control system, the connections to the National Gaming Commission, or the payment processing. Article 4.13 of the Resolution of November 16th, 2011 (Resolución de 16 de noviembre de 2011, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición por la que se desarrollan las especificaciones técnicas que deben cumplir los sistemas técnicos de juego objeto de licencias otorgadas al amparo de la Ley 13/2011, de 27 de mayo, de regulación del juego), establishes a group of obligations in the context of change management. Article 10 of the Resolution of July 12th, 2012 (Resolución de 12 de julio de 2012 de la Dirección General de Ordenación del Juego por la que se aprueba la disposición que establece el modelo y contenido del informe de certificación definitiva de los sistemas técnicos de los operadores de juego y se desarrolla el procedimiento de gestión de cambios) complements the requirements in regard to the process of change management. The purpose of this document is to explain from a technical and operational standpoint, all the matters related to the management change process resulting from the previous regulations. 3

4 5. Change management process and obligations with Dirección General de Ordenación del Juego Change management is an inherent part of the life cycle of any information systems. The operator is supposed to count on a formal internal approval process of all changes, which must involve the change request as well as the approval by the concerned. In this context, the obligations established by Dirección General de Ordenación del Juego (DGOJ) must be taken into account. The aim of the following diagram is to summarize in a graphical way those stages of the change management procedure, where the obligations established by the DGOJ must be considered. 4

5 This diagram does not include the case of change of extraordinary emergency, which is explained later in section number 8. Change evaluation During this process, the operator is required to assess whether the change is "substantial" or not. The assessment of whether a change is "substantial" falls primarily on the operator, which is the one that has most knowledge about their own system. Annex I of this document provides guidance on the assessment criteria to follow in order to consider the substantiality of a change. After the assessment, there are two cases: a) On the one hand, if the operator concludes with a well-founded analysis, that the change is not substantial, the operator can proceed to make the change, without making any notification to the DGOJ nor being subject to any assessment by the DGOJ. b) On the other hand, if the operator concludes with a well-founded analysis, that the change is substantial, the operator must certify the change. This process is explained later. At any rate, change requests and decisions shall be recorded and may be subject to subsequent audit. If DGOJ considered substantial any changes made previously on critical components, DGOJ could require the operator to proceed with the certification of the changes, without prejudice to the possibility of requiring the operator to proceed with the withdrawal of the change until it is certified and approved. Certification of substantial changes Before deploying a substantial change in the production environment, it is required a certification of the new version of the system. The reports for the certification of substantial changes will be drawn up according to the Resolution of July 12th, 2012, (Resolución de 12 de julio de 2012, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición que establece el modelo y contenido del informe de certificación definitiva de los sistemas técnicos de los operadores de juego y se desarrolla el procedimiento de gestión de cambios), with some considerations and exceptions, which are explained in Annex II. Apply for DGOJ approval This request must be made through the Registry or procedures established in article38.4 of the Act 30/1992 (Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común). This request must be made by the legal representative. 5

6 In the near future, it will be enabled a link in the website of DGOJ for online processing of this procedure. If the change affects several licenses, just one application in regard to all the licenses subject to change, can be provided. As detailed below, a template is presented that the operator can use to apply for the DGOJ approval. Subdirección General de Inspección del Juego Dirección General de Ordenación del Juego Ministerio de Hacienda y Administraciones Públicas C/ Atocha Madrid Subject: "APPLICATION FOR THE APPROVAL FOR SUBSTANTIAL CHANGES" - Identification of the legal representative (name, ID, position, address for notification, etc.). - Identification of the operator. - Identification of the license(s) subject to change. - Brief description of the reason for the change. - Brief description of the attached documentation. - Documentation attached (according to the instructions explained in Annex II). Certification evaluation In one month s time the DGOJ must answer the application. If after this period, the DGOJ had not answered, the answer can be considered positive. Substantial change implementation The operator must not deploy the substantial change in the production environment before the DGOJ approval, whether expressly or by administrative silence. Non-substantial change implementation When the assessment of the operator determines that the change is not substantial, the operator can implement the change without any notification to the DGOJ. In both cases, before implementing a change, it is required to keep copies of the binaries of the software elements of all software versions that have been used in the technical system in the last four years. These copies could be subject to following audits. 6

7 Documenting change in the quarterly report Any changes implemented on a critical element must be documented in a report which will be sent every three months to the DGOJ. All information in regard to the content of the report is detailed in Section 6. Submission of the quarterly report The quarterly changes report submission will be made through the DGOJ website. All the information related to the submission is provided is Section 6. 7

8 6. Quarterly changes report Any changes on critical components shall be recorded on the quarterly changes report. The report consists of a list of changes implemented, including at least, for each change, a change identifier, the date of implementation, a qualitative description of the change, and a well-founded explanation for those changes which were not considered substantial. The description is required to be conceptual and qualitative, including the aim of the change and the scope of the critical components affected. It is allowed to group similar changes which respond to the same aim. The format of the report must be one or more text documents or, alternatively, tables. Either binaries or hash codes are not required to be included. Although it is suggested to draw up one single report referring to all licenses, different reports are allowed as long as the scope of each one is explained. Documentation may be drawn up as far as possible in Spanish, or otherwise, in English. The scope of the report shall be the changes implemented on critical components. 8

9 The quarterly report will be drawn up according to the following template: INDEX OF THE REPORT 1. Substantial changes in case of extraordinary emergency 2. Substantial changes certified and approved by DGOJ. 3. Non-substantial changes in those cases where the criterion of the operator disagrees on the criterion of DGOJ (according to Annex I). 4. Non-substantial changes in those cases where the criterion of the operator agrees on the criteria of DGOJ (according to Annex I). For each item, indicate: Change identifier Execution date Conceptual description Justification for nonsubstantial changes * Justification is particularly necessary in Section 3: cases where the operator's criterion disagrees on DGOJ's criterion. * In those cases where there is a change of software version of one of the critical elements, it must be included the identifier of the new version deployed in the conceptual description. It will be enabled a link in the official website of DGOJ for the submission of the report, in the following section: Procedimientos y Servicios electrónicos/ Para el operador/ Obligaciones de comunicaciones/ Información periódica After completing a first form in regard to the identification, a second form will be available to include: Quarterly changes report. Descriptive Operator Questionnaire (*) 9

10 * Please note: In order to simplify the information to be provided by the operator, it has been published a new version of the Descriptive Licenses Questionnaire which unifies the information on all licenses in one single file. This questionnaire updates the one published on 2012 August, the 29 th. This questionnaire will be published on the website. It is important to remark the fact that the questionnaire refers to one operator, instead of one license and operator, as before. The quarterly report is required to be sent as follows: First Report: on the months of January, February and March. Delivery Period: in May from the 1 st to the 10 th. Second Report: on the months of April, May and June. Delivery Period: in August from the 1 st to the 10 th. Third report on the months of July, August and September. Delivery Period: in November from the 1 st to the 10 th. Fourth report on the months of October, November and December. Delivery Period: in February from the 1st to the 10th. 10

11 7. Operators service In case of doubt by the operator about the substantial nature of a change, the operator may apply to the operator service provided by the DGOJ. However, since the decision about whether a change is substantial or not, must be based on a thorough knowledge of the system and a risk analysis, the answer provided by the DGOJ will consist in general and conceptual guidelines, to help the operator to take the final decision. In any case, the operator is required to provide enough information in order to enable the assessment of the scope of the change on the critical component. The operator service can be required as follows: To: dgoj.control@minhap.es Subject: "CHANGE MANAGEMENT QUERY" and a title for the query. body: Identification of the operator(s) or certification authority (ies) which enquiries. Identification of the one who performs the query. Query. Queries are supposed to be drawn up in Spanish as far as possible, or otherwise, in English. 11

12 8. Change management process in case of extraordinary emergency and obligations with Dirección General de Ordenación del Juego The following diagram shows the obligations established by the DGOJ in the change management process for a substantial change in case of extraordinary emergency. The instructions for each process are the same as those explained in section 5, with the following exceptions. To report to the DGOJ about the change 12

13 The operator must inform DGOJ about a substantial change implementation in case of an extraordinary security emergency by as follows: To: dgoj.control@minhap.es Subject: "EXTRAORDINARY EMERGENCY CHANGE" / "NAME" where "NAME" refers to the name of the operator body: Identification of the operator. Identification of the license. Identification of the one who informs. Description of the extraordinary emergency situation, explaining the risks. Description of the emergency corrective actions to be performed Reports are supposed to be drawn up as far as possible in Spanish, or otherwise, in English. Besides, it is suggested to report about the emergency situation before the change implementation or in the following 24 hours after the implementation. 13

14 Certification of substantial change It is required to provide all the documentation in regard to the certification of the change in one month s time after reporting to the DGOJ about the change or, otherwise, since the completion of the first emergency corrective actions. It is also required to submit a report explaining the exceptional circumstances of the emergency situation and the consequent risk to the security of the technical system. This application must be submitted through the Registry or procedures established in Article 38.4 of the Act 30/1992 (Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común), according to the following instructions: Subdirección General de Inspección del Juego Dirección General de Ordenación del Juego Ministerio de Hacienda y Administraciones Públicas C/ Atocha Madrid Subject: "APPLICATION FOR APPROVAL OF A SUBSTANTIAL CHANGE IN CASE OF EXTRAORDINARY EMERGENCY". - Identification of the legal representative (name, ID, position, address for notification, etc.). - Identification of the operator. - Identification of the license(s) subject to change. - Brief description of the reason for the change. - Reference to the date when the operator reported to the DGOJ on the extraordinary security emergency change. - Brief description of the attached documentation. - Documentation attached. Documentation in regard to the certification (according to the instructions explained in Annex II). Report explaining the exceptional circumstances of the emergency situation and the consequent risk to the security of the technical system In the near future, it will be enabled a link in website of DGOJ for online processing of this procedure. 14

15 9. ANNEX I. GUIDELINES TO ASSESS THE SUBSTANTIAL NATURE OF A CHANGE IN THE TECHNICAL SYSTEM The substantial nature of a change must be considered as a proportionality between the risk assessment associated to the change, the need to make the gambling market flexible and the cost of the approval process for operators, as well as for the Administration and, indirectly to the citizens. Moreover, it must be also considered the risks as a consequent of not implementing the change. Risks should be assessed according to the objectives of the Act 13/2011 (Ley 13/2011, de 27 de mayo, de regulación de juego), such as: - The impact on the subjective prohibitions control, - Responsible gaming, - The compliance of the gaming with the legal framework - Fair play and proper operation, - The authenticity and correct computation of gambling, - The traceability of operations, - Monitoring by DGOJ through the Internal Control System - The security of the game and especially in the participant access, - Data recovery for any kind of incidence Technical systems can be very complex. The change management process is continuous and the changes respond to a great variety of reasons. Besides, dependencies between hardware, software and network elements which form the central game unity, in addition to the coupling between the different software components, complicate the definition of substantial change over the elements classified as critical. Therefore, it is difficult to define exhaustively in advance what kind of changes should be considered "substantial." And there is not any exhaustive definition of substantial in the regulation. As a consequent, the first assessment of whether a change should be rated as "substantial" is carried out by the operator, since it is the leading expert in its technical system. DGOJ shall watch over all operators to apply similar criterion, according to the legislation and a proportionality criterion. In addition to this, DGOJ will answer to any question submitted in related to this issue. For this reason, it has been set below the criterion of DGOJ in qualifying a change as "substantial". The operator could apply different criterion according to the distinctive features of its system, but is shall be well-founded explained in the quarterly changes report. DGOJ s criterion has been set according to the following classification: 1. Substantial changes in functionality. 2. Substantial changes in security. 3. Substantial changes related to user registration. 4. Substantial changes concerning the gambling account. 15

16 5. Substantial changes related to game software. 6. Substantial changes related to RNG 7. Changes that might not be substantial The criterion of DGOJ will be updated according to new cases detected in one operator, which can be representative to the rest, as well as according to the evolution of the market. Substantial changes in functionality 1. A new website, or merging multiple websites in one. 2. A new gaming software, whether it is a self-development or whether it is provided by another company. 3. A major change in the game software version previously approved. 4. In case there are remarkable differences between the final environment to the user and the environment where the certification for the general approval process took place, it is required to certify again the final environment. Note: in the last four cases, the functionality certification report to submit shall be complete. Substantial changes in security 1. A new Data Center or a move to a new location of the existing ones. - The security certification report shall be complete. 2. New technologies or participant access applications (for example, applications for smartphones). a. It is required to submit a security certification report in regard to the "security in communication with participants" and "penetration testing and vulnerability analysis". b. Note: technologies or participant access applications should also be evaluated from the point of view of functionality. In particular, in regard to the different critical component, there have been identified the following cases: Substantial changes related to user registration. Changes in the procedures for validating users identity, in the treatment of responses, in the logic of the checks as well as in the users activation. For example: Changes in queries to RGIAJ (Registro General de Interdicciones de Acceso al Juego). Changes in the source of information used: documentary system, new identity verification service, etc. New information sources providers. Minor changes in the software that modifies the activation and validation logic. 16

17 Substantial changes concerning the gambling account Big changes in the accounting model. Changes in the integration model with game providers Substantial changes related to game software New variants of game, for those cases where the rules specify different variants: Bingo, Poker and Black Jack. In the case of sports betting, including new risks and events providers. In the case of sports betting, including live betting. Substantial changes related to RNG Changes that modify the generation of random numbers and the processing of this information. Changes that might not be substantial On functionality: 1. General purpose systems which have been previously approved, or changes on these components, which do not modify the logic of the critical component: a. network elements, b. wiring c. hardware systems d. general purpose software systems (operating systems, development libraries, database, web server, application server, etc.). 2. Changes made on critical software component: a. For corrective maintenance, correction of errors or bugs b. Affecting only the performance c. Affecting only the interface d. To implement promotional policies, as long as they do not involve major changes in the game account and ensure the traceability of operations. On security: 1. Changes in policies, processes, procedures, technical or organizational measures, as long as they do not result in weakening or loss of guarantees on the previously security level approved. Security must be understood as an iterative and incremental process. The addition of new items or changes on the technical system shall be reflected in the security documentation, but not necessarily be subject to recertification. 17

18 10. ANNEX II. CONSIDERATIONS ON THE REPORTS FOR CERTIFICATION OF A SUBSTANTIAL CHANGE Before deploying a substantial change in the production environment, it is required a certification of the new version of the system. The reports for the certification of substantial changes will be drawn up according to the Resolution of July 12th, 2012, (Resolución de 12 de julio de 2012, de la Dirección General de Ordenación del Juego, por la que se aprueba la disposición que establece el modelo y contenido del informe de certificación definitiva de los sistemas técnicos de los operadores de juego y se desarrolla el procedimiento de gestión de cambios), with the following considerations: Description of the technical system In the application for authorization for a substantial change, it shall be provided the updated description of the technical system, the particular rules in the case of singular licensing, and the updated version of the operator descriptive questionnaire. Note: it has been published a new version of this questionnaire. The new version refers to one operator (instead of one license and operator). Functionality Certification Report. Test environment In the certification of substantial changes, it is not required to work out the certification tests in the production environment. As it is required to certificate the new version of the system before deploying it in the production environment, the tests for the certification process can be performed in any pre-production environment. The certification authority must certify that the results obtained in the test environment can be extrapolated to what would have been obtained in the production environment. For integration testing on the internal control system (A.5.1 and B.4.1), testing can be performed with fictitious data, as closely to real as possible, taking the appropriate considerations. Therefore, testing with real data is not required. Scope of certification report The scope of certification must be the whole license, subject to change. In other words, the process of certification by the certification authority should be tackled from a global vision of the license subject to change. In this sense, if the certification authority may explain in a well-founded analysis that the substantial change affects only to a part of the system, some certification reports and tests worked out for the previous approval process can be reused. This analysis shall be provided on a report. Some examples are presented below. 1. Changes which affect only the functionality or only security: 18

19 The certification authority, in its sole discretion, can assess the scope of the changes and decide whether a change affects only the functionality, but not the security. In this case, it must be provided a signed statement by the certification authority certifying that the change does not affect security, and therefore, previous final security certification reports can be reused. It shall be remarked the code of the report previously submitted, as well as the date, the name of the certification authority and the scope of the report. Similarly, the certification authority, in its sole discretion, can assess the scope of the changes and decide whether a change affects only the security, but not the functionality. In this case, it must be provided a signed statement by the certification authority certifying that the change does not affect functionality, and therefore, previous final functionality certification reports can be reused. It shall be remarked the code of the report previously submitted, as well as the date, the name of the certification authority and the scope of the report. 2. The certification authority, in its sole discretion, can assess that the scope of the change affects only one of the certification reports previous submitted, but not the rest. In this case, the certification authority may reuse any certification reports submitted before which are not affected by the change. In this case, it must be provided a signed statement by the certification authority: a) List of certification reports reused, related to the license subject to change, indicating - the report code, - issue date, - certification authority - scope of the report b) an explanation which certifies that the change does not affect the rest of the certification reports mentioned above, and indicating that, all the reports together certify overall, the whole system under the scope of the license, subject to change. 3. Certification reports must be complete. 19

20 The report must refer to every technical requirement, integration test and specific analysis. The certification authority, in its sole discretion, must assess the scope of the change, and can decide not to repeat those tests which are not affected by the change. This fact must be explained in the report. It can be rewritten the results of the previous tests, or indicated a reference to the previous report. 4. In the new certification reports submitted, in Section 2, "Certification Object Description", it shall be explained: a. The different variants of the game under the scope of certification, b. The websites and trade names, c. The different access channels certified (Internet, SMS, IVR, in person ) d. The different client access applications certified (flash web access, client for PC, client for Smart phones, etc.) 5. Report of compliance on personal data protection The report on compliance to personal data protection shall be repeated only if the following cases: a. For Spanish operators (subject to Spanish jurisdiction on the protection of personal data): i. Changes in the location of their data centers or their providers ones, dealing with personal data, when they are moved from one EU country to the rest of the world or vice versa. b. For non-spanish operators (not subject to Spanish jurisdiction for the protection of personal data): i. Changes in the location of their data centers or their providers ones, dealing with personal data, when they are moved from Spain to another EU country or vice versa. ii. Changes in the location of their data centers or their providers ones, dealing with personal data, when they are moved from one EU country to the rest of the world or vice versa. 20