ITS Change Management

Policy 14.11

Related Policies

I. Reason for Policy

The purpose of this policy is to establish a structured and documented process for managing changes to Dakota State University’s information technology systems, infrastructure, and applications. Effective change management ensures that all modifications are evaluated, tested, approved, implemented, and reviewed in a manner that minimizes risk to the stability, integrity, and security of university operations.

This policy supports compliance with regulatory and institutional requirements, including those under FERPA, GLBA, HIPAA, and other applicable standards.

Scope. This policy applies to all individuals involved in planning, developing, testing, approving, or implementing changes that may affect DSU’s production IT systems, networks, or services. It includes employees, contractors, vendors, and third-party service providers. Changes covered under this policy include (but are not limited to):

1. Hardware: Additions, removals, or modifications to computing or network equipment.
2. Software: Installations, upgrades, major patches, or removals affecting production environments.
3. Applications and Databases: Updates, migrations, or schema modifications impacting system integrity or data.
4. Security Controls: Changes affecting authentication, authorization, encryption, or other security configurations.
5. Network Components: Firewall, router, switch configurations, or topology adjustments.
6. Telephony or VoIP Systems: Significant installations or relocations that affect service delivery.

II. Definitions

1. Change Request (CR). A formal record in the change management system describing the proposed modification, rationale, risk, and plan.
   Change Manager. The ITS role responsible for overseeing and coordinating all change management activities.
   Change Owner. The individual responsible for planning, executing, and validating an approved change.
   Change Review Team (CRT). The review body (CIO, Change Manager, and relevant technical representatives) responsible for reviewing and approving/rejecting changes.
2. CIO (Chief Information Officer). Campus Chief Information Officer/Vice President of Technology is the department head for the DSU (Dakota State University) technology department.
3. Emergency Change. A high-priority change required to resolve a critical incident or prevent imminent service disruption.
4. Institutional Data. Data for which institutional resources or institutionally owned, leased, licensed, or provided technology systems are used to create, manage, transmit, process, or store it, including administrative, instructional, operational, and research data. When institutional systems, devices, funding, or networks are used to create or process research data, the resulting data is considered institutional data regardless of where the researcher is physically located or which device is used at the moment of creation.
5. ITS. Information Technology Services. The official technology department for Dakota State University and subsumed departments.
6. Production Systems. Production systems are services, applications, infrastructure, or integrations that are in active operational use and whose disruption could materially impact university operations, users, or institutional data.

III. Statement of Policy

1. All changes to DSU information systems must follow the established Change Management process.
   No changes to production systems may be made without prior review, approval, and documentation through the Change Management System, except emergency changes that follow the emergency process.
2. Change Classification. Changes shall be categorized by risk, impact, and urgency:
   
   1. Standard Change: Pre-approved, low-risk, repeatable changes with documented procedures.
   2. Normal Change: Requires full assessment, approval, and scheduling through CRT.
   3. Emergency Change: Implemented quickly to resolve a major outage or risk; requires post-implementation review.
3. Governance and Roles
   
   1. Change Requestor: Submits a CR with justification, risk, and test results.
   2. Change Manager: Reviews submissions, coordinates CRT review, ensures documentation, and reports metrics.
   3. Change Review Team (CRT): Approves, defers, or rejects proposed changes.
   4. Change Owner: Executes approved changes, tests, documents outcomes, and ensures closure.
4. Risk and Impact Analysis. Each CR must include:
   
   1. Description of change and affected systems
   2. Risk and impact analysis (service disruption, security, compliance, cost)
   3. Testing and validation plan
   4. Backout or rollback procedures
5. Access Control. Only authorized ITS personnel may make or approve production changes.
   Change management systems and related configuration tools must enforce role-based access control.
6. Training and Awareness. ITS will provide training on change management procedures and expectations for all personnel involved in change processes.
7. Compliance and Enforcement. Failure to follow this policy may result in disciplinary action, revocation of access privileges, or other sanctions consistent with university and Board of Regents policy.

Exclusions

The following are excluded or governed by separate processes:

1. Routine operational tasks
   1. Individual student, faculty, or staff workstations used for coursework or daily job functions
   2. Installation of standard academic or productivity software on endpoint devices
   3. Routine operating system updates, patches, or reboots performed as part of normal device maintenance
   4. Common support activities such as password resets or user provisioning
2. Environment changes not affecting production systems.
3. Temporary failovers or maintenance on redundant systems.
4. Disaster recovery activities during an actual event; however, permanent changes from recovery must follow this policy afterward.

Exceptions

Any exceptions to this policy must be formally requested, documented, and approved by the CIO. Exceptions shall be granted only in exceptional circumstances and may include additional controls or compensating measures to mitigate associated risks.

IV. Procedures (Major)

1. Initiation
   
   1. The requester submits a CR in the Change Management System.
   2. The CR includes description, justification, affected assets, test plan, risk assessment, and rollback plan.
2. Review and Approval
   
   1. The Change Manager reviews for completeness and potential conflicts.
   2. The CRT meets weekly (or as needed) to evaluate Normal and Major changes.
   3. Approval outcomes: Approved, Deferred, or Rejected.
3. Communication and Scheduling
   1. ITS communicates approved implementation schedules to affected stakeholders.
   2. All changes must be scheduled outside peak operational hours when feasible.
4. Testing and Implementation
   1. Change Owner conducts pre-deployment testing in a controlled, non-production environment.
   2. Upon CRT approval, the change is implemented according to the approved plan and documented in the Change Management System.
5. Emergency Change Process
   1. Emergency changes may be authorized by the CIO or designee.
   2. The Change Owner must document justification, steps taken, and risks.
   3. The CRT must review and validate the emergency change at its next meeting.
6. Post-Implementation Review and Closure
   1. The Change Owner confirms success or identifies issues.
   2. Any deviations, lessons learned, or follow-up actions are documented.
   3. The Change Manager updates record and officially closes the CR.
7. Reporting. The Change Manager provides quarterly summaries to the CIO, including:
   1. Number and type of changes
   2. Success/failure rates
   3. Number of emergency changes
   4. Change-related incidents or rollbacks

V. Related Documents, Forms, and Tools

NIST SP 800-128 - Guide for Security-Focused Configuration Management
NIST SP 800-53 Rev 5 - Security and Privacy Controls for Information Systems and Organizations
CISA CRR Supplemental Resource Guide Vol 3

VI. Policy History

Adopted: 02/09/2026