Technology Maintenance and Change Approval
Technology requires regular maintenance.
Patching, upgrades, configuration changes, certificate renewals, lifecycle work, and other planned activities are necessary to keep services secure, reliable, supported, and useful.
Maintenance should therefore be treated as planned work rather than something performed only when time becomes available.
Within the ISS Hierarchy of Priority, recurring maintenance is generally 3 — Sustainment / Stewardship.
Managers are responsible for protecting appropriate time for this work so that necessary maintenance is not continually displaced by tickets and projects.
Maintenance Often Includes Change
Most technology maintenance involves changing something.
Examples may include:
- Applying operating system patches
- Updating applications
- Upgrading firmware
- Renewing certificates
- Updating network configurations
- Replacing equipment
- Modifying integrations
- Installing vendor releases
- Changing security settings
- Updating infrastructure components
When maintenance can affect an ISS service, it must be evaluated through the Change Management process.
Step 1 — Determine Service Criticality
The first question is:
How critical is the affected service to College operations?
ISS services are ranked from Critical through Very Low according to their importance to College operations.
Critical and Major Services
Maintenance affecting a Critical or Major service requires approval from:
- CITO
- Appropriate Vice President
- MCC Leadership Team
This approval is required regardless of the individual maintenance activity's calculated risk.
For these services, the criticality of the service itself establishes the required approval path.
Services Below Major
For services ranked below Major, the proposed change must be evaluated using the Change Risk Matrix.
Step 2 — Determine Change Risk
The Change Risk Matrix evaluates two factors:
Impact × Probability
Together, these produce an overall risk rating between 1 and 5.
5 represents the highest risk.
Impact
Impact measures how many people or College functions could be affected and how severely they could be affected if the change fails.
Consider:
- Number of people affected
- Number of departments or locations affected
- Importance of the service
- Effect on teaching and learning
- Effect on College business operations
- Security implications
- Data implications
- Integration dependencies
- Difficulty of recovery
Probability
Probability measures the likelihood that something unintended will occur.
Consider:
- Whether the change has been performed before
- Experience of the employees performing the change
- Complexity
- Vendor guidance
- Availability of testing
- Number of dependencies
- Availability of rollback
- Whether multiple systems must change together
For example, a change that has been performed successfully many times may carry a lower probability than one the team has never performed before.
Step 3 — Determine Required Approval
For services ranked below Major, the risk rating determines the approval requirement.
| Risk Rating | Approval Required |
|---|---|
| 5 | CITO and MCC Leadership Team |
| 4 | CITO and appropriate Vice President |
| 1–3 | CITO |
The approval process can therefore be summarized as:
Critical or Major Service
→ CITO + Appropriate Vice President + MCC Leadership Team
Service Below Major
→ Calculate Impact and Probability
Risk 5
→ CITO + MCC Leadership Team
Risk 4
→ CITO + Appropriate Vice President
Risk 1–3
→ CITO
Employees must obtain the required approval before proceeding with the change.
Step 4 — Determine Whether the Change Is Disruptive
The change must also be classified as disruptive or non-disruptive.
Disruptive Maintenance
Maintenance is disruptive when a service or system is expected to be:
Customers are likely to experience something different during the maintenance.
Non-Disruptive Maintenance
Maintenance is non-disruptive when no outage or degradation is expected and customers are not expected to experience a meaningful interruption.
A non-disruptive classification does not mean the change has no risk.
The disruptive or non-disruptive classification helps determine the required communication and notice period.
Step 5 — Determine Communication Requirements
All planned changes must be placed on the appropriate ISS maintenance calendar.
Additional communication is determined by the risk rating and whether the maintenance is disruptive or non-disruptive. The existing standard specifically establishes maintenance-calendar posting and additional email or website communication based on risk and service impact.
The following table defines the minimum communication and approval requirements.
Changes affecting Critical or Major services must follow the Risk 5 communication requirements regardless of the individual change's calculated risk. For planned maintenance, this means a minimum of four weeks' notice via email and the maintenance website unless the CITO authorizes the work as Emergency or Expedited Maintenance as defined below.
| Risk | Type | Minimum Communication Required | Approval Required |
|---|---|---|---|
| 5 | Disruptive or Non-disruptive | 4 weeks' notice via email and website | CITO and MCC Leadership Team |
| 4 | Disruptive | 2 weeks' notice via email and website | CITO and appropriate Vice President |
| 4 | Non-disruptive | 2 weeks' notice via email and website | CITO and appropriate Vice President |
| 3 | Disruptive | 2 weeks' notice via email and website | CITO |
| 3 | Non-disruptive | 1 week's notice via email and website | CITO |
| 2 | Disruptive | 2 weeks' notice via email and website | CITO |
| 2 | Non-disruptive | 1 week's notice via website | CITO |
| 1 | Disruptive | 2 weeks' notice via email and website | CITO |
| 1 | Non-disruptive | 1 week's notice via website | CITO |
These time periods represent the minimum communication requirements.
Teams may communicate earlier when additional notice would help the College prepare for the change.
Critical and Major Services Override the Approval Column
The approval column in the communication table applies to services ranked below Major.
For a Critical or Major service, the required approval remains:
- CITO
- Appropriate Vice President
- MCC Leadership Team
regardless of the individual change-risk rating.
The communication requirements remain an important part of planning the maintenance, but service criticality establishes the required approval path.
Emergency and Expedited Maintenance
Normal maintenance should follow the established communication and approval timelines whenever possible.
There are situations, however, when waiting for the normal timeline would create unacceptable risk or prevent ISS from responding appropriately to an urgent College need.
Emergency Maintenance
Emergency Maintenance is work that must begin immediately or as soon as technically practical to address an emergent condition.
Examples may include:
- Applying a patch or mitigation for an actively exploitable or zero-day cybersecurity vulnerability.
- Taking action to prevent an imminent service outage.
- Responding to an active service failure.
- Addressing a condition that presents an immediate risk to College systems, data, security, or operations.
Any College leaders or stakeholders who would normally participate in the approval process should be notified as soon as practical.
Emergency Maintenance should still be:
- Recorded on the ISS maintenance calendar as soon as practical.
- Documented appropriately.
- Communicated to affected customers and stakeholders as soon as practical.
- Validated after implementation.
- Reviewed afterward when the impact or circumstances warrant a retrospective.
Emergency Maintenance is an exception for genuine emergent conditions. It should not be used simply because normal planning or communication deadlines were missed.
Expedited Maintenance
Expedited Maintenance is urgent work that does not require immediate emergency action but cannot reasonably wait for the normal communication timeline.
Expedited Maintenance must be expected to occur within the next five days.
Examples may include:
- A vendor identifies an urgent correction that should be implemented quickly.
- A developing condition is likely to create a service problem if not addressed soon.
- A time-sensitive security, operational, or technical issue requires action before the normal maintenance notice period can be completed.
The normal advance-notice period may be shortened, but the team should provide as much notice as practical.
Required approvals based on service criticality and change risk should still be obtained within the expedited timeline.
Expedited Maintenance should be:
- Added to the ISS maintenance calendar.
- Communicated to affected customers and stakeholders before the work begins whenever practical.
- Documented using the normal maintenance process.
- Tested and validated as appropriate.
- Completed with appropriate rollback or recovery planning.
Expedited Maintenance is intended for work that is genuinely urgent, not as a substitute for normal maintenance planning.
Communication During Emergency and Expedited Maintenance
Emergency and Expedited Maintenance do not eliminate the responsibility to communicate.
They modify when communication can reasonably occur.
For Emergency Maintenance, communication should occur as if an incident is occuring. Therefore, a similar incident coordination communication must be sent as soon as the maintenance starts and when it ends.
For Expedited Maintenance, communication should occur before the work begins and provide as much advance notice as practical within the shortened timeline.
Maintenance Calendar
All maintenances must be placed on the ISS maintenance calendar.
The maintenance calendar helps ISS:
- Understand what is changing.
- Avoid conflicting maintenance.
- Coordinate resources.
- Prepare the Help Desk.
- Identify competing College events.
- Provide visibility to managers and teams.
- Coordinate customer communication.
Calendar placement does not replace required approval or communication.
Select an Appropriate Maintenance Time
Maintenance should be scheduled to reduce unnecessary impact on College operations.
Consider:
- Classes
- Registration
- Financial processing
- Payroll
- Major College events
- Academic deadlines
- Other scheduled maintenance
- Vendor availability
- Required staff availability
- Time needed for validation
- Time needed for rollback
Established maintenance windows should be used when appropriate.
Large or disruptive changes may need to occur during periods of lower College activity or between academic terms.
Convenience for ISS should not be the only factor used to select a maintenance time.
Prepare the Maintenance Plan
The amount of documentation should match the complexity and risk of the work.
For significant maintenance, the plan should normally identify:
- Service or service offering affected
- Service criticality
- Purpose
- Change owner
- Technical team
- Planned date and time
- Expected duration
- Disruptive or non-disruptive classification
- Impact
- Probability
- Risk rating
- Expected customer impact
- Prerequisites
- Implementation steps
- Testing or validation
- Rollback or recovery plan
- Dependencies
- Vendor involvement
- Communication requirements
- Required approvals
- Related ticket or project information
Routine, well-understood maintenance may use a simpler plan, but it must still meet the applicable approval, calendar, and communication requirements.
Prepare the Help Desk
When maintenance may create customer questions or observable changes, the Help Desk should receive enough information to support customers effectively.
The Help Desk should understand, as appropriate:
- What is changing.
- When the change will occur.
- Who may be affected.
- What customers may experience.
- Whether a workaround exists.
- When normal service is expected.
- Who is performing the work.
- Where current status information can be found.
Customers should not learn about a planned maintenance activity before the employees expected to support them.
During Maintenance
The responsible employee or team should follow the approved plan while remaining alert to unexpected conditions.
If conditions materially change, the team should determine whether continuing remains appropriate.
Unexpected risk may justify:
- Pausing the work
- Rolling back
- Escalating to a manager
- Contacting a vendor
- Revising the implementation approach
- Activating Incident Management
Following a plan does not mean continuing blindly when circumstances change.
Verify Before Declaring Success
After maintenance, verify that the service is operating as expected.
Validation may include:
- Service health checks
- Application testing
- Authentication testing
- Integration testing
- Customer-impact checks
- Monitoring review
- Help Desk confirmation
- Vendor validation
A maintenance activity is not complete simply because the final technical step was performed.
Close the Change
When appropriate, complete the record by documenting:
- Actual completion time
- Whether the change succeeded
- Unexpected conditions
- Rollback activity
- Outstanding issues
- Required follow-up
- Documentation changes
- Customer communication
- Lessons learned
If maintenance causes a significant outage or degradation, follow the Incident Management and retrospective requirements in this chapter.
Connection to Our Values
People Matter because maintenance decisions affect people's ability to use College services.
Communication Matters because planned disruption should not become an unnecessary surprise.
Integrity Matters because we tell people what we intend to do, obtain the required approval, follow the approved plan, and report what actually occurred.
Excellence Matters because regular, well-managed maintenance keeps services secure, reliable, supportable, and sustainable.