Management with appropriate authority shall approve an information security policy taking into consideration the service requirements, statutory and regulatory requirements and contractual obligations. Management shall:

1. communicate the information security policy and the importance of conforming to the policy to appropriate personnel within the service provider, customer and suppliers.
2. ensure that information security management objectives are established.
3. define the approach to be taken for the management of information security risks and the criteria for accepting risks.
4. ensure that information security risk assessments are conducted at planned intervals.
5. ensure that internal information security audits are conducted.
6. ensure that audit results are reviewed to identify opportunities for improvement.

ITG has implemented the ISO 27001 which ensures communication, objectives, definition criteria for acceptance of risks, planned assessments, audits, and opportunities for improvement are performed.

Information security controls

The service provider shall implement and operate physical, administrative and technical information security controls in order to:

1. preserve confidentiality, integrity and accessibility of information assets;
2. fulfill the requirements of the information security policy;
3. achieve information security management objectives;
4. manage risks related to information security.

These information security controls shall be documented and shall describe the risks to which the controls relate their operation and maintenance. The service provider shall review the effectiveness of information security controls. The service provider shall take necessary actions and report on the actions taken. The service provider shall identify external organizations that have a need to access, use or manage the service provider’s information or services. The service provider shall document, agree and implement information security controls with these external organizations.

Information security changes and incidents

1. new or changed information security risks;
2. potential impact on the existing information security policy and controls.

Information security incidents shall be managed using the incident management procedures, with a priority appropriate to the information security risks. The service provider shall analyze the types, volumes and impacts of information security incidents. Information security incidents shall be reported and reviewed to identify opportunities for improvement.

NOTE The ISO/IEC 27000 family of standards specifies requirements and provides guidance to support the implementation and operation of an information security management system.

Change management

A change management policy shall be established that defines:

1. CIs which are under the control of change management;
   1. This procedure applies to staff and managers who contemplate proposing and implementing changes within the Company. All changes related to company defined configuration items are to be processed and implemented through a Change Management System.
   2. All Corrective Actions resulting from internal or external audits.
   3. Preventive Actions from internal audits or requests resulting from staff initiatives involving software modifications and issuance of Requirements.
   4. Identified Major Initiatives either related to infrastructure or to Business initiatives involving new products or services and which may require the preparation of a Decision Analysis Resolution (DAR).
2. criteria to determine changes with potential to have a major impact on services or the customer.
   1. Change Categories: Changes are classified as major, significant, standard, minor and urgent.
      1. Major and Significant Changes are substantial modifications to configuration items (CIs) and require compliance with all the requirements of this Change Management Procedure. Approval by the Change Authority is necessary.
      2. Standard and Minor Changes are routine staff actions not requiring modifications or issuance of Software Modifications. Approval by the Change Authority is not necessary. Examples are: Website bugs, updates of standard reports, IT service upgrades and the like.
      3. Urgent Changes are those which require immediate resolution.
3. Removal of a service shall be classified as a change to a service with the potential to have a major impact. Transfer of a service from the service provider to the customer or a different party shall be classified as a change with potential to have a major impact.
4. The service provider shall document and agree with the customer the definition of an emergency change. There shall be a documented procedure for managing emergency changes.
   1. Authorized staff member contacts Executive Management directly, defines the nature of the emergency and the change needed, as well as potentially affected departments and any known risks associated with the proposed change.
   2. Executive management evaluates risk, impact and benefits, then either denies the request or approves change concept and implementation of the change on an emergency basis.
   3. Authorized staff member performs steps a and b of the major change procedure, assigns resources designated or approved by Executive Management, and notifies stakeholders, including the default change authority, that an urgent change is taking place.
   4. Implementation proceeds.
   5. Change Manager ensures that the change request is completed appropriately following all appropriate steps of a major change as quickly as possible.
5. All changes to a service or service component shall be raised using a request for change. Requests for change shall have a defined scope.
6. All requests for change shall be recorded and classified. Requests for change classified as having the potential to have a major impact on the services or the customer shall be managed using the design and transition of new or changed services process. All other requests for change to CIs defined in the change management policy shall be managed using the change management process.
7. Requests for change shall be assessed using information from the change management process and other processes.
   1. The service provider and interested parties shall make decisions on the acceptance of requests for change. Decision-making shall take into consideration the risks, the potential impacts to services and the customer, service requirements, business benefits, technical feasibility and financial impact.
8. Approved changes shall be developed and tested.
9. A schedule of change containing details of the approved changes and their proposed deployment dates shall be established and communicated to interested parties. The schedule of change shall be used as the basis for planning the deployment of releases.
10. Requests for change shall be analyzed at planned intervals to detect trends. The results and conclusions drawn from the analysis shall be recorded and reviewed to identify opportunities for improvement.

Release and deployment management

1. The service provider shall establish and agree with the customer a release policy stating the frequency and type of releases.
2. The service provider shall plan with the customer and interested parties the deployment of new or changed services and service components into the live environment. Planning shall be coordinated with the change management process and include references to the related requests for change, known errors and problems which are being closed through the release. Planning shall include the dates for deployment of each release, deliverables and methods of deployment.
3. The service provider shall document and agree with the customer the definition of an emergency release. Emergency releases shall be managed according to a documented procedure that interfaces to the emergency change procedure.
4. Releases shall be built and tested prior to deployment. A controlled acceptance test environment shall be used for the building and testing of releases.