Scribd Logo
Upload

Welcome to Scribd!

  • 1 views

    System Change Management Policy - 2023

    Uploaded by

    Bii Joash Kiprotich

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    System Change Management Policy - 2023

    Uploaded by

    Bii Joash Kiprotich
    1 views3 pages

    Original Title

    System Change Management Policy_2023

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    1 views3 pages

    System Change Management Policy - 2023

    Uploaded by

    Bii Joash Kiprotich

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 3

    SYSTEM CHANGE MANAGEMENT POLICY

    POLICY NO.: IT700-


    RESPONSIBLE
    Chief Information Officer
    ADMINISTRATOR:
    RESPONSIBLE OFFICE: Information Technology

    ISSUE/EFFECTIVE DATE: 05/13/2013

    REVISION DATE: 10/10/2023

    1.0 POLICY PURPOSE


    Mission critical systems are comprised of key hardware, software, and even processes and guiding
    policies which allow the university and its constituents to function in the completion of the
    organization’s mission. Mission critical systems include (but are not necessarily limited to) the
    following: Enterprise Resource Planning Systems, Student Information Systems, Learning
    Management Systems, Email Systems, Network Systems, Storage Systems, Backup Systems,
    Electrical Systems, Environmental Systems, Policies, Guidelines, Procedures, Access and so on.

    2.0 TO WHOM THE POLICY APPLIES


    IT Staff

    3.0 POLICY STATEMENT


    When modifying mission critical systems within an HSSU Information Technology context, it is
    critical the IT staff members not only note that change has occurred but also formally issue a
    change request and have it reviewed before implementation.

    4.0 DEFINITIONS
    N/A

    5.0 RESPONSIBILITIES
    MISSION CRITICAL SYSTEMS CHANGES

    • Programming changes to the institution’s ERP/SIS environments and/or platforms on


    which they rely (CX, JICS, eLearning, FinishLine, Informix, Linux, WMWare, FEITH).
    This includes Jenzabar SMOs.
    • Security and access changes to the institution’s ERP/SIS environments (CX, JICS, e-Racer,
    FinishLine, Informix, Linux, WMWare, FEITH) that transcend base permissions needed
    by faculty, staff, and students accessing MYHSSU environments
    • Programming and/or security changes to network routing and switching infrastructure that
    allows greater user access than was provided in the previous configuration
    • Programming and/or security changes to server hardware and software that allows
    increased user access than was provided in the previous configuration.
    • Reconfiguration of the HSSU physical and/or virtual infrastructures, backup processes, or
    networked mass storage devices.
    • Reconfiguration of client software and software sets, licensing, security, and/or other
    significant alterations to base configurations of software, hardware, and systems access
    provided by the university.
    • Terminated user accounts (no deletion without review).
    The above changes must be documented through the institution’s helpdesk ticketing
    application.

    NON-MISSION CRITICAL SYSTEMS CHANGES

    Changes that will be documented through the HSSU change process but do not normally
    require prior approval or formal change planning include (but are not limited to) the
    following:

    • OS updates in Windows Server environments


    • OS patch applications in Windows Server environments
    • Virus definition updates in Windows Server environments
    • Client OS/licensed software updates
    Changes will be documented in the HSSU Help Desk using the Change Management option for
    ticket creation. In situations where the change requires administrative IT authorization, the IT staff
    member issuing the ticket should enter the on-duty administrator as individual who requested
    service. The IT staff member should then discuss the change with the administrator before
    executing the change.

    EMERGENCY CHANGES VS CRITICAL CHANGES

    When an emergency change is needed, IT Services staff and managers will generally follow
    the protocol outlined in the document entitled ‘Procedures for System Emergencies for IT
    Staff and Managers.’ Emergency changes always require the submission of a Help Desk
    change ticket, regardless of their severity level. Emergency changes may be temporary or
    permanent. Permanent emergency changes to mission-critical must be followed up by
    creating supporting documentation through the institution’s Change Management Planner.
    Examples of emergency changes include (but are not limited to the following):

    • Disabling a single user’s access to ERP/SIS systems due to a security incident (requires a
    help-desk change ticket marked as a change in user access).
    • Modifying all user access to ERP/SIS systems to contain a security incident (requires a
    help-desk change ticket and documentation through the Change Management Planner).
    It is important to note that in both examples, the change precipitates an incident management
    protocol, which requires further investigation and research by the institution’s Security Incident
    Response team.

    Emergency changes to mission-critical systems are rare but may be required when circumstances
    dictate. Circumstances may include but are not limited to the following:
    • Units are unable to complete urgent business functions (business continuity is interrupted).
    • A security risk has been detected is unable to be contained.
    • Institutional data assets are corrupted or at risk of becoming corrupt.
    • Environmental changes create unacceptable conditions for system operations.
    The following are examples of Critical changes that are not to be treated as emergency changes
    and should be referred to an IT administrator for change planning:

    • Programming changes to improve a process or outcome.


    • Interruption of production systems (e.g. rebooting, upgrades, software installations) as part
    of a maintenance procedure during normal business hours.
    • Temporarily modifying user access to complete a project/process related to ERP/SIS
    systems.
    The above examples illustrate the need for planning and managing risk to systems. All change
    incurs new risk, which must be considered before a change is introduced into a functional system.
    Incurring unnecessary risk in a situation that is not an emergency will result in the institution
    applying sanctions against an employee who incurs the risk. This includes performance
    markdowns on evaluations, demotion and/or reassignment, probation, or termination of the
    employee in situations of extreme negligence or repeated acts of negligence.

    6.0 CONSEQUENCES FOR VIOLATING THIS POLICY


    Incurring unnecessary risk in a situation that is not an emergency will result in the institution
    applying sanctions against an employee who incurs the risk. This includes performance
    markdowns on evaluations, demotion and/or reassignment, probation, or termination of the
    employee in situations of extreme negligence or repeated acts of negligence.

    7.0 RELATED INFORMATION


    N/A

    You might also like