S6 Department – Change Management Procedures
| This is the Document Release Information | |
| Article Number: | 7CAV-S6-006 |
| Scope: | S6 Department – Change Management Procedures |
| Version: | Version 1.1 |
| Effective Date: | 06SEP26 |
| Last Modified Date: | 06SEP26 |
| Approving Authority: | S6 1IC |
| Point of Contact: | S6 2IC |
Purpose and Scope
This Standard Operating Procedure establishes the minimum requirements for planning, approving, implementing, and documenting changes to S6-managed systems and services.
A change record is required when planned work may materially affect:
- Service availability.
- Security or access.
- Regimental data.
- Integrations.
- Shared configurations.
Routine support and documented recurring tasks do not require a separate change record unless they involve unusual risk, disruption, or deviation from the normal procedure.
An existing XenForo ticket may serve as the change record. A duplicate ticket is not required.
Change Approval
The required approval level is based on the change's risk and impact:
- Applicable Lead: Routine, low-risk, reversible changes affecting one team or service.
- S6 2IC: Changes involving expected downtime, elevated access, security controls, multiple services, or significant user impact.
- S6 1IC: High-risk, widespread, difficult-to-reverse, or major infrastructure changes.
Approval must be documented before implementation unless the emergency-change requirements in Section 4 apply.
Approval authorizes only the work described in the change record. A material increase in scope, risk, or impact requires additional review and approval.
Minimum Change Process
Every planned change requiring a change record must follow four steps:
- Document: Record what is changing, why it is needed, the expected impact, the implementation method, how success will be validated, and how the change will be reversed if necessary.
- Approve: Obtain approval from the required authority before beginning work.
- Implement: Perform the approved work and validation. Stop and seek further direction if an unexpected issue materially increases the risk or impact.
- Close: Record the result, validation, problems, rollback, and any required follow-up.
Emergency Changes
An emergency change may proceed before normal approval only when delay would worsen:
- An active service outage.
- A security threat or unauthorized access.
- A risk of data loss.
- Another serious operational impact.
The person performing the change must:
- Act within their existing authority and access.
- Notify the S6 1IC and S6 2IC as soon as practical.
- Limit the change to the minimum action required.
- Document the change and result as soon as practical.
S6 Headquarters must review the emergency change after implementation and identify any required follow-up.
Responsibilities and Communication
The person implementing the change is responsible for maintaining the change record, following the approved plan, validating the result, and documenting completion.
The approving authority is responsible for confirming that the risk, impact, validation, and rollback information are reasonable for the proposed change.
Affected users or stakeholders must be notified in advance when disruption is expected.
Emergency maintenance may proceed without advance notice when providing notice is impractical or would unreasonably delay necessary action. In that event, affected users or stakeholders must be notified as soon as practical during or after the maintenance and informed of the outcome.
S6 Headquarters may require additional review, testing, communication, or approval when the circumstances warrant it.
Related Procedures
All changes must comply with 7CAV-S6-002 (Acceptable Use Policy).
Any suspected or confirmed security incident identified during a change must be reported and handled under 7CAV-S6-007 (Incident Reporting and Escalation Procedures).
Appendix A – Minimum Change Record
Staff Instructions: Use this record only when required by Section 1. Brief answers are acceptable. Use "N/A" when a field does not apply.
Change Summary:
[What is changing, why is it needed, and what system or service is affected?]
Schedule and Expected Impact:
[When will the change occur, who may be affected, and is disruption expected?]
Implementation, Validation, and Rollback:
[How will the change be completed, how will success be confirmed, and how will the previous state be restored if necessary?]
Approval:
[Approving authority and approval date.]
Result and Follow-Up:
[Record the outcome, validation result, any rollback or unexpected issue, and remaining work.]