Internal Use

Change Management Policy

Dispel

Document Control

1. PURPOSE AND SCOPE

1.1 Purpose

The purpose of this policy is to define how Dispel plans, approves, implements, and reviews changes to systems and services in a controlled manner that minimizes unplanned outages and security risks.

1.2 Scope

This policy applies to:

• All changes to Dispel-managed production systems, applications, infrastructure, and networks.
• Changes to configurations, code, infrastructure-as-code, and supporting services that may impact confidentiality, integrity, availability, or compliance.
• All Covered Persons involved in requesting, approving, implementing, or reviewing changes.

1.3 Regulatory and Framework Alignment

2. POLICY STATEMENTS

2.1 Management Commitment

Management Commitment Statement

Senior Management at Dispel is dedicated to the protection of our information assets, industrial control systems, and Protected Health Information (PHI). We assume full accountability for the effectiveness of our security program, ensuring it is integrated into all business processes and aligned with our strategic goals. To maintain compliance with ISO 27001, IEC 62443, HIPAA, and NIST 800-53, we formally commit to:

• Resource Provisioning: Providing the necessary financial, technical, and human resources to sustain a robust security posture.
• Risk-Based Governance: Approving security policies and overseeing a continuous risk management process that prioritizes both data privacy and operational safety.
• Operational Resilience: Supporting the security of industrial automation and control systems (IACS) to ensure safety and reliability.
• Continuous Oversight: Conducting regular management reviews to evaluate program performance, audit results, and opportunities for improvement.

2.2 Primary Policy Statement

Dispel SHALL ensure that all in-scope changes are planned, reviewed, approved, tested (where appropriate), and documented prior to implementation.

2.3 Secondary Policy Statement

• Emergency changes SHALL follow an expedited but documented process and be reviewed after implementation.
• Changes SHALL include rollback plans and clear responsibilities.

3. REQUIREMENTS

3.1 Change Management Governance

Objective: Establish governance over change management.

Mandatory Activities:

1. The Policy Owner SHALL own this policy and associated procedures and ensure they are reviewed at least annually.
2. Change management roles and authorization levels SHALL be defined and documented.
3. This policy and procedures SHALL be disseminated to Covered Persons; review, acceptance, and acknowledgement SHALL be required initially and at least annually.

Required Outputs:

• Current change management policy and procedures.
• Records of acknowledgements for relevant roles.

Security Controls: NIST SP 800-53 CM-1.

3.2 Standard Change Process

Objective: Define the process for planned changes.

Mandatory Activities:

1. For planned changes, Dispel SHALL:
   • Record the change in an approved change tracking system with a unique identifier.
   • Specify scope, implementation steps, testing requirements, and rollback plan.
   • Obtain required approvals prior to implementation.
2. Changes SHALL be scheduled at times that minimize business impact.
3. Changes SHALL be implemented only by authorized personnel.
4. Post-implementation validation SHALL confirm that the change had the intended effect and did not introduce unexpected issues.

Required Outputs:

• Change records including approvals, test evidence, and rollback plans.

Security Controls: NIST SP 800-53 CM-3, CM-4.

3.3 Emergency and Unplanned Changes

Objective: Control emergency and unplanned changes.

Mandatory Activities:

1. Emergency changes (e.g., critical vulnerability fixes) MAY follow an expedited approval process but SHALL still be documented.
2. Post-implementation reviews SHALL:
   • Confirm whether the change was effective.
   • Identify any follow-up actions or improvements to the process.
3. Unplanned or unintended changes SHALL be investigated, with corrective actions and documentation as needed.

Required Outputs:

• Emergency change records and post-implementation review notes.

Security Controls: NIST SP 800-53 CM-3, CM-4.

3.4 Software and Configuration Changes

Objective: Ensure software and configuration changes are controlled and traceable.

Mandatory Activities:

1. Production systems SHALL only contain approved, tested code and configurations.
2. Version control systems SHALL be used to manage source code and configuration-as-code.
3. Access to change production configurations and code SHALL be restricted to authorized personnel and protected with strong authentication.
4. Changes to production SHALL be deployed via controlled pipelines, with peer review and testing appropriate to the risk.

Required Outputs:

• Version control history and change logs.
• Records of code reviews and test results.

Security Controls: NIST SP 800-53 CM-5.

4. ROLES AND RESPONSIBILITIES

4.1 Policy Owner

Responsibilities:

• Owns this Change Management Policy.
• Ensures alignment with configuration management and SDLC processes.
• Coordinates periodic reviews and updates.

4.2 Change Advisory / Review Function

Responsibilities:

• Review high-impact or high-risk changes.
• Confirm that risk, testing, and rollback considerations are addressed.
• Recommend approval, rejection, or deferral.

4.3 System Owners / Administrators

Responsibilities:

• Initiate and implement changes in accordance with this policy.
• Ensure testing and validation are completed.
• Maintain system documentation and change records.

5. PROCEDURES

5.1 Change Management Lifecycle (High-Level)

6. MONITORING AND COMPLIANCE

6.1 Compliance Monitoring

Compliance with this policy SHALL be monitored through:

• Reviews of change records and approvals.
• Audits of production configurations against baselines.
• Reviews of incidents related to failed or unauthorized changes.

6.2 Metrics and Reporting

The following metrics SHALL be tracked and reported at least annually to the Policy Owner and senior management:

6.3 Non-Compliance Consequences

Failure to comply with this policy and procedures may result in:

• Increased risk of outages or security incidents.
• Revocation or restriction of access for Covered Persons who repeatedly fail to follow change procedures.
• Disciplinary action for employees and contractors, consistent with Dispel HR policies and applicable law.

7. EXCEPTIONS AND WAIVERS

7.1 Exception Process

Exceptions to this policy SHALL:

1. Be submitted in writing by the requesting party.
2. Identify the specific policy or procedural requirements for which an exception is sought.
3. Include justification and business impact.
4. Describe compensating controls or mitigation measures.
5. Define exception duration and remediation plan.

7.2 Exception Approval Authority

8. DEFINITIONS

Change: Any addition, modification, or removal of hardware, software, or configuration that could impact services.

Emergency Change: A change that must be implemented as soon as possible to resolve a critical issue or vulnerability.

9. REFERENCES

9.1 Internal References

• System Configuration Management Policy and Procedures.
• Software Development Life Cycle / System Development Lifecycle documents.
• Incident Response Policy and Procedures.

9.2 External References

• NIST SP 800-53, CM family.
• ISO/IEC 27001 and related guidance on change and configuration management.

10. DOCUMENT HISTORY

11. APPROVAL SIGNATURES

APPENDICES

Appendix A: Supporting Change Management Procedures

This appendix may include:

• Detailed change request templates.
• Example approval workflows.
• Checklists for code, configuration, and infrastructure changes.

Appendix B: Additional Guidance and Examples

This appendix may include:

• Example change scenarios and lessons learned.
• References to industry best practices for change management.