Version 1.3.0 of 1 July 2012
Contents 1 Introduction... 3 1.1 Authority... 3 1.2 Objective... 3 1.3 Target audience... 3 1.4 Version... 3 1.5 Enquiries... 3 2. Framework for managing system changes... 4 2.1 Responsibility in relation to handling changes... 4 2.1.1 The licence holder s responsibility... 4 2.1.2 Responsibility for managing system changes... 4 3. Schedule for implementing changes... 5 3.1 Planning of changes... 5 3.2 Identification of configuration... 5 3.3 System structure and choice of configuration items... 5 3.4 Identification of components (assets)... 6 3.5 Information about configuration items... 6 3.6 Geographical location of components... 6 3.7 Classification of components... 6 3.8 Configuration baseline... 7 4. Managing system changes... 7 4.1 Reasons for system changes... 7 4.2 Evaluation of system changes... 8 4.3 Approval of system changes... 8 4.3.1 Rejection of changes recommended by suppliers of business functionality... 9 4.3.2 Approved changes, recommended by suppliers of business functionality... 9 4.3.3. Rejected changes recommended by suppliers of gaming functionality... 9 4.3.4 Approved changes recommended by suppliers of gaming functionality... 9 4.3.5 Implementation of a new Random Number Generator (RNG) and changes to an existing RNG... 9 4.3.6 Implementation of new games... 10 4.3.7 Changes in existing offering of games... 10 4.4 Implementation and verification of system changes... 10 4.4.1 Changes to the components classified as 3... 10 4.4.2 Changes to the components classified as 2... 11 4.5 Presentation of a status of system changes... 11 4.6 Reporting... 11 4.7 Change and configuration audit... 12 Version 1.3.0 of 1 July 2012 Page 2 of 12
1 Introduction 1.1 Authority This document Spillemyndigheden s Change Management Programme has been issued by Spillemyndigheden (the Danish Gambling Authority) under the Gambling Act (Act No. 848 of 1 July 2010 as later amended) and the executive orders on online casinos, online betting and land-based betting. It is part of the overall certification programme, which consists of the documents Spillemyndigheden s requirements for accredited testing organisations, Spillemyndigheden s change management programme and Spillemyndigheden s technical standards. 1.2 Objective The document specifies the minimum requirements which licence holders shall satisfy when carrying out changes to their gambling system. 1.3 Target audience The document is intended for licence holders, suppliers, accreditation bodies and testing organisations. 1.4 Version This document is Version 1.3.0 of 1 July 2012. Spillemyndigheden will revise the certification programme on an on-going basis, making the latest version and the version history accessible at Spillemyndigheden s website: http://spillemyndigheden.dk. If the certification programme is modified, as a rule certifications already issued will remain in force. It is important to emphasise that only the Danish version is legally binding and that the English version holds the status of guidance only. 1.5 Enquiries All enquiries concerning this document should be sent in writing to Spillemyndigheden at the following address: spillemyndigheden@skat.dk or Spillemyndigheden Helgeshøj Allé 9 DK-2630 Taastrup Version 1.3.0 of 1 July 2012 Page 3 of 12
2. Framework for managing system changes The licence holder shall plan its internal procedures for managing changes in a way which ensures that the particular changes and their effect on the overall system can be identified at all times. Part of the internal procedure shall ensure that the licence holder will have a manager who is responsible for managing system changes, see section 2.1.2. This manager shall also take charge of preparing a formal change planning document, describing all the specific procedures and ensuring that the various measures are coordinated. The is structured in a way that allows routine changes etc. to be carried through in an expedient and controlled manner, while having minimal impact on the licence holder s business procedures. The licence holder shall ensure certification according to Spillemyndigheden s change management programme, and it shall be completed before the commencement of the licence holder s offering of betting and online casino services. The change management of the licence holder shall be certified at all times. The licence holder shall ensure that the change management of the licence holder is subject to on-going certification of the adherence to Spillemyndigheden s with an interval of no more than 12 months. 2.1 Responsibility in relation to handling changes 2.1.1 The licence holder s responsibility The licence holder is responsible for changes in its betting and online casino systems irrespective of whether such changes have been carried through by the licence holder or a third party on behalf of the licence holder. A licence holder, who offers betting and/or online casino gambling shall clarify and describe responsibilities and authorities in connection with the completion and approval of the change process. If the system changes are managed by one of the licence holder s suppliers, the licence holder shall ensure that the supplier carries through corresponding procedures and complies with the requirements of this document. 2.1.2 Responsibility for managing system changes The licence holder shall appoint one or more among its staff to take overall responsibility for system changes. This may be organised as a committee. The responsible manager(s) shall possess sufficient experience and competence in relation to change management and hold a key position in the company in relation to change management. The responsible manager(s) need not necessarily handle the system changes personally, as changes and their relevance will vary extensively in relation to the particular change. It shall be handled in cooperation with other members of staff at the company or its suppliers in order to ensure qualified decisions in all areas. The company shall keep a log of the persons who have been involved in the decision process. Prior to approval of changes the responsible manager(s) shall confirm that: Version 1.3.0 of 1 July 2012 Page 4 of 12
The proposed system changes are consistent with Spillemyndigheden s technical standards, The proposed system changes are necessary, The consequences will be acceptable, The proposed system changes have been carefully considered, documented and categorised and The planned action to implement the system changes in documents, hardware and/or software is satisfactory. 3. Schedule for implementing changes 3.1 Planning of changes The formal change plan shall contain a description showing that the system changes Will be incorporated in and aligned with the supplier s change plans, Shall be documented and approved by the management, Shall have been controlled by the responsible manager, Shall show the configuration to be used, Shall refer to the licence holder s and the supplier s relevant procedures whenever possible and Shall establish who is responsible for changes throughout the system and the components life cycles and with what powers. 3.2 Identification of configuration The configuration described below is a minimum requirement. The purpose is to allow identification of all the different parts of the system configuration so that the implications of system changes for every part will be assessed in the context of the purpose of this document. 3.3 System structure and choice of configuration items The choice of configuration items and the links between them should describe the system structure. Configuration items should be chosen based on considerations of whether their functional and physical properties can be handled separately. The selection criteria should comprise: Regulatory requirements, Critical aspects in relation to security risk (risk in relation to confidentiality, integrity and availability) and accountability, New or changed technology, design or development and Interface to other configuration items. The number of the chosen configuration items should optimise the possibility of controlling the product. The selection of configuration items should be started at the earliest possible stage of the product s life cycle. Configuration items should be assessed on an ongoing basis during development of the product. Any configuration item that may have implications for confidentiality, integrity or accountability should be assessed on the basis of the criteria listed above. Version 1.3.0 of 1 July 2012 Page 5 of 12
3.4 Identification of components (assets) The licence holder shall cooperate with its suppliers to map out all hardware and software components that are used in the operation of betting and online casino services. Components that may have impact on security (integrity, confidentiality and availability) and/or are responsible for payment or gambling systems shall be recorded in a register of components. The level of detail of the records in this register is to be decided by the licence holder and its suppliers. If a licence holder chooses to keep a general register (in which the gambling system is the only component, for example) all changes to the gambling system will be classified as a change to a significant configuration item and thereby subject to appropriate control. If the level of detail in the register is higher, however (software RNG class, for example), it will be possible to handle changes to less important configuration items by less intervening measures. The items shall have a unique code, version number and identification characteristic, ensuring that an independent auditor will be able to inspect/check some or all components at any given time and determine whether they have deviated from the starting point. The items shall be recorded in the register of components. The owner of each component should be identifiable from the register. The owner shall be the one, who is responsible for component changes. If such an owner cannot be identified it shall be the manager(s) responsible for the component, see section 2.1.2. The register of components along with the log of changes shall constitute the foundation which identifies the gambling system. 3.5 Information about configuration items The information about configuration items shall include both a definition of the item and information about the operation of the product which will provide unique identification of an item, thus allowing an auditor to assess whether it is in conformity with the plan (checksum of source code, object code and executable code, for example). Information about configuration items of significant relevance, see section 3.7, shall be included or referred to in the register of components. Information about the configuration should be relevant and traceable. The numbering shall be unique and ensure adequate control of the configuration item in question. 3.6 Geographical location of components The geographical location of all servers and hardware components shall be recorded in the register of components. 3.7 Classification of components All items identified in the register of components shall be classified using the following matrix: Confidentiality refers to confidential information about customers. Integrity refers to the integrity of the systems functionality and the information the systems include. Version 1.3.0 of 1 July 2012 Page 6 of 12
Availability refers to the availability of the information concerning customer entitlements. Accountability refers to the activity of all users (customers, staff, third parties) on all components in the system. All components shall be given a relevance code on a scale from 1 to 3 based on the relevance of the configuration items relative to creating or protecting all properties of the system (confidentiality, integrity, availability or accountability). The relevance codes are: 1 = no relevance (cannot have any negative impact on the system s properties), 2 = some relevance (may have impact on the system s properties) and 3 = significant relevance (system properties are specifically related to the configuration item). When the components are to be classified it may be relevant to assess the material difference between betting and online casino and the variety of risks they involve (including customer entitlement and fairness). 3.8 Configuration baseline The configuration baseline contains information about the configuration providing a definition of the product, which has been approved by an accredited testing organisation. The configuration baseline along with approved changes to it will form the basis of the new configuration baseline. The configuration baseline shall be approved every twelve months by an accredited testing organisation. 4. Managing system changes The extent of a proposed change to the system will affect the degree of control necessary to handle the system change. The measures taken to manage system changes shall be documented and the documentation shall include the following items: A description of, the reasons for and a registration of the changes, A categorisation of the changes in respect of complexity, resources and planning, An evaluation of the consequences of the changes, Details indicating how the changes are to be approved and Details indicating how the changes will be implemented and tested. 4.1 Reasons for system changes Prior to the internal approval of system changes by the responsible manager (s), all proposed changes shall be identified and documented. Proposed system changes should typically include the following information: Version 1.3.0 of 1 July 2012 Page 7 of 12
The configuration item(s) and related information to be changed, including details on their designation and current status of revision, A description of the proposed change, Details concerning other configuration items or information that may be affected by the changes, The employee or supplier who has prepared the proposal and the date of its preparation, The reason for the change and The type of change. The status of the change process, related decisions and measures shall be documented. A typical method to be applied in documenting changes is using a form with a unique identification number in order to assist the identification and traceability of the form. The condition for implementing changes recommended by suppliers of business functions should be that the changes are reasonable and justified. 4.2 Evaluation of system changes Proposed system changes shall be evaluated and the evaluation shall be documented. This evaluation shall be conducted in accordance with the purpose of the Gambling Act and the associated executive orders, based on ISO/IEC 31010 Risk management - Risk assessment techniques, and shall contain: Technical benefits to be gained from the proposed changes, Risks involved in the changes, Implications for compliance with current legislation, Confidentiality of customer data, Integrity of functionality and data, Availability of customer data and funds and Accountability when users interact with the system. Even though changes recommended by suppliers of business functions will generally be considered to be reasonable and justified, the licence holder should still evaluate such changes taking into account the criteria listed above. 4.3 Approval of system changes A procedure shall be established for the formal approval of system changes. Once a proposed change has been evaluated the manager(s) responsible shall review the evaluation and decide whether the change should be approved or not. Even if changes recommended by suppliers of business functions will generally be considered to be reasonable and justified, the licence holders should still formally approve or reject such changes. All decisions as well as the underlying considerations concerned with system changes should be recorded in a log. Notice of decisions should be circulated to the relevant stakeholders inside and outside the organisation, including the relevant accredited testing organisation. The accredited testing organisation shall analyse the basis on which all decisions that deviate from the suppliers recommendations have been made. All decisions shall be handled separately. The accredited testing organisation shall certify whether the licence holder s decision is justified. Version 1.3.0 of 1 July 2012 Page 8 of 12
4.3.1 Rejection of changes recommended by suppliers of business functionality When the licence holder decides not to follow a supplier s recommendation, reasons for the decision shall be recorded. The reasons for not following the supplier s recommendations shall be given to Spillemyndigheden through the accredited testing organisation once every three months. The accredited testing organisation shall analyse the basis of each decision not to follow the supplier s recommendations separately. The accredited testing organisation shall show if the licence holder s decision is justified. 4.3.2 Approved changes, recommended by suppliers of business functionality When a licence holder decides that it will be expedient to follow the recommendations given by a supplier, the change shall be implemented in a way that prevents the components described in the register of components, see section 3.4, from being exposed to any unnecessary risks. The time between supplier(s) recommendation(s) and implementation shall be justified in a log. Evidence of the implementation of supplier s recommendation shall be maintained in the same log. The log shall subsequently be transferred to the accredited testing organisation and Spillemyndigheden on an annual basis. 4.3.3. Rejected changes recommended by suppliers of gaming functionality In case the licence holder decides that it is not expedient to follow the recommendations issued by a supplier of gaming functionality, the licence holder shall give the reasons for the decision. The documented reasons shall include an assessment for the components described in the register of components, see section 3.4, of the potential risks. The reason for rejecting the supplier s recommendations shall be given Spillemyndigheden through the accredited testing organisation every three months. The accredited testing organisation shall analyse the basis of each decision to reject the supplier s recommendations separately. The accredited testing organisation shall show whether the licence holder s decision is justified. 4.3.4 Approved changes recommended by suppliers of gaming functionality When a licence holder decides that it is expedient to follow the recommendations from a supplier this shall be done in such a way that the components described in the register of components, see section 3.4, will not be exposed to any unnecessary risks. The time between supplier(s) recommendation(s) and implementation shall be justified in a log. Evidence of the implementation of supplier s recommendation shall be maintained in the same log. The log shall subsequently be transferred to the accredited testing organisation and Spillemyndigheden on an annual basis. 4.3.5 Implementation of a new Random Number Generator (RNG) and changes to an existing RNG The implementation of a new RNG and changes to an existing RNG shall be notified with Spillemyndigheden five working days before the implementation is carried out. Version 1.3.0 of 1 July 2012 Page 9 of 12
4.3.6 Implementation of new games The offering of new games, which utilises a subset of Spillemyndigheden s existing standard records not previously utilised by the licence holder, shall be notified with Spillemyndigheden five working days before the offering commences. The offering of new games, which cannot utilise a subset of Spillemyndigheden s existing standard records, shall be notified with Spillemyndigheden three weeks before the offering commences and shall not commence without prior dialogue with Spillemyndigheden. Guidance: The implementation of new games, which does not affect how the licence holder utilises Spillemyndigheden s standard records, can commence without prior notification with Spillemyndigheden. 4.3.7 Changes in existing offering of games Changes to the existing offering of games, which would affect the utilisation of Spillemyndigheden s existing standard records by the licence holder, shall be notified with Spillemyndigheden five working days before the offering is changed. Changes to the existing offering of games, which would affect the utilisation of Spillemyndigheden s existing standard records to an extent where an existing subset can no longer be used by the licence holder, shall be notified with Spillemyndigheden three weeks before the offering is changed and shall not commence without prior dialogue with Spillemyndigheden. Guidance: Changes to the existing offering of games, which does not affect how the licence holder utilises Spillemyndigheden s standard records, can commence without prior notification with Spillemyndigheden. 4.4 Implementation and verification of system changes This section applies to changes of components (assets) classified as 2 and 3 as described in section 3.7. After implementation the conformity with the approved changes shall be verified. This verification shall be registered so that it will be traceable. Completed changes shall be reported to the relevant accredited testing organisation (please note that for low risk changes this may be done by keeping a routine log of changes). 4.4.1 Changes to the components classified as 3 The relevant accredited testing organisation shall assess and approve the licence holder s evaluation of the system change as made out pursuant to section 4.2 in all changes to the components of the gambling system classified as 3 ( of significant relevance ) pursuant to section 3.7 and certify all changes no later than in direct continuation of the implementation, whenever changes are made. Where a licence holder has an internal function dedicated to undertaking quality assurance of change management and this function is manned with appropriately skilled staff as well as being separated from the function implementing system changes, the relevant accredited testing organisation can allow changes to occur without certification, whenever changes are made. The accredited testing organisation shall assess, approve and certify these changes every three months and the certification shall clearly state whether this method has been used. The option of a certification interval of three months when dealing with changes to components classified as 3 is only available to licence holders. The option is not available to suppliers and vendors without a licence to offer online casino and/or betting in Denmark. Version 1.3.0 of 1 July 2012 Page 10 of 12
4.4.2 Changes to the components classified as 2 The relevant accredited testing organisation shall assess and approve the licence holder s evaluation of the system change as made out pursuant to section 4.2 in all changes to gambling functionality when it involves the components of the gambling system classified as 2 ( of some relevance ) pursuant to section 3.7 and certify them every three months. The relevant accredited testing organisation shall assess and approve the licence holder s evaluation of the system change as made out pursuant to section 4.2 in all changes to business functionality when it involves the components of the gambling system classified as 2 ( of some relevance ) pursuant to section 3.7 and certify them every twelve months. Guidance to the accredited testing organisation: The analysis of the risk involved in changes should be carried through based on an appropriate sampling method and it shall take account of the assessed relevance of and risk involved in the change. Thereby a complete audit of all changes will not be necessary. All certifications prepared by accredited testing organisations shall be forwarded to Spillemyndigheden. 4.5 Presentation of a status of system changes The presentation of the status of system changes relates to the gambling system and configuration information. The licence holder shall ensure that the configuration status is registered on an ongoing basis and that it shows the status of the gambling system configuration. The log recording the configuration status should include: Information about system setup (such as identification number, title, dates of coming into force, audit status, change history and its commencement relative to the configuration baseline), The configuration of systems and components (such as part number, product design or version status), The status of the issue of new product configuration information, A risk analysis and decisions concerned with making the decision as to whether the changes will be approved or not, Implementation and Certification (see Spillemyndigheden s requirements for accredited testing organisations ). The information on the configuration and the system s evolution shall be recorded in a way that specifies cross-referencing and the connections necessary to submit the required reporting, see section 4.6. The report on the status in respect of changes shall ensure that a detailed audit can follow the audit trail through the changes and illustrate where the changes were made and who was responsible for implementing the changes in the set-up (including but not limited to source code). The level of detail in the reporting of changes should be proportionate to the 1-3 classification, see section 3.7. 4.6 Reporting A variety of types of reporting is necessary in order to handle changes as well as the configuration. These reports may cover particular configuration items or the entire system. Typical reports will contain: Version 1.3.0 of 1 July 2012 Page 11 of 12
a list of information about the configuration of a product which is part of a specific configuration baseline a list of configuration items and their configuration baseline details about the current status in respect of audits and change history status reports on changes and deviations and details of the status of supplied and maintained system components, including serial numbers or the like and revision status. 4.7 Change and configuration audit An audit of changes and configuration shall be carried through every twelve months by an accredited testing organisation. The purpose of the annual audit of changes and configuration is to confirm that the Change Management Programme has been complied with in the course of the year and that the log will show the status of the system and changes correctly. Version 1.3.0 of 1 July 2012 Page 12 of 12