Change management policy

A change management policy defines how changes to IT systems, applications, infrastructure, code, configuration, and production environments are requested, assessed, approved, implemented, reviewed, and evidenced. Its job is to reduce operational and security risk, prevent unauthorized changes, and leave a clear record that the process operated in practice.

This article is about IT and security change control. Not HR restructuring, workplace consultation, employee communications, or broad organizational transformation programs.

What is a change management policy?

A change management policy is the governing document for controlled changes to technology assets. It should tell teams:

• What changes are in scope.
• Who can request, approve, implement, and review changes.
• How risk and impact are assessed.
• What testing, validation, rollback, and communication are required.
• What evidence must be retained.

The policy should cover more than formal production releases. It can also apply to cloud configuration changes, identity and access changes, network changes, infrastructure changes, security tooling changes, database changes, code deployments, and supplier-triggered changes that affect in-scope systems.

For compliance programs, the policy also connects operations to evidence. For example, SOC 2’s Trust Services Criterion CC8.1 addresses changes to infrastructure, data, software, and procedures, including authorization, documentation, testing, approval, and implementation. The criterion does not prescribe one ticket format or approval model, it does make change control relevant to audit readiness (AICPA Trust Services Criteria).

What should a change management policy include?

A practical policy should be short enough to operate, but specific enough to remove ambiguity. Include these sections.

Purpose
State why the policy exists: to ensure technology changes are assessed, authorized, tested, implemented, documented, and reviewed in a controlled way.

Scope
Define the systems, environments, teams, and change types covered. Include production systems, supporting infrastructure, security-relevant configurations, software releases, and supplier-managed services where those changes can affect in-scope systems.

Definitions
Define key terms such as change, emergency change, standard change, high-risk change, unauthorized change, rollback, change owner, approver, and change register.

Roles and responsibilities
Identify who can request, assess, approve, implement, validate, and close changes. Separate approval from implementation where practical, especially for higher-risk changes.

Change types
Define categories such as:

• Standard or pre-approved low-risk changes.
• Normal planned changes.
• Significant or high-risk changes.
• Emergency changes.
• Unauthorized changes.

Risk assessment
Require each change to be assessed for system criticality, production exposure, security impact, customer or user impact, data sensitivity, compliance relevance, dependency impact, and rollback complexity.

Approval requirements
Define approval expectations by risk tier. Avoid hard-coding a single universal model; approval should reflect the organization’s systems, operating model, and obligations.

Testing and validation
Describe what evidence is expected before and after implementation. Testing may include peer review, automated tests, security validation, configuration review, staging validation, or business-owner acceptance, depending on the change.

Failure handling and rollback
Require teams to document how failures will be addressed and how the system will be returned to a secure state where the change could fail or create material impact.

Implementation and communication
Define how changes are scheduled, who must be notified, and how maintenance windows or customer-impacting changes are communicated.

Documentation and evidence retention
Specify where tickets, approvals, test results, deployment records, rollback steps, review notes, and change logs are retained.

Emergency changes
Allow expedited approval where delay would create material operational, security, or business risk. Require retrospective documentation, validation, and review.

Unauthorized changes
Define how unapproved changes are identified, investigated, remediated, and reviewed to prevent recurrence.

Exceptions
Require exceptions to be documented, justified, approved by an appropriate owner, time-bound where possible, and reviewed.

Review cadence
Assign policy ownership and require periodic review when systems, tools, risks, ownership, or compliance obligations change.

ISO/IEC 27001 should be treated in a risk-based way. ISO/IEC 27001 uses a risk-based process to determine necessary information-security controls, and Annex A is a reference set considered through that process rather than a universally applicable checklist (ISO/IEC JTC 1/SC 27).

How IT/security changes should move from request to review

The policy should map to a workflow teams can actually follow in tickets, engineering tools, deployment systems, cloud consoles, identity systems, or a change register.

A practical flow looks like this—or, more accurately, can look like this:

1. Submit the change request.
   The requester opens a ticket or record with the target system, description, reason, planned timing, owner, and expected impact.

2. Document scope and business reason.
   The change owner explains what will change, why it is needed, and whether production systems, sensitive data, customers, or security controls are affected.

3. Assess risk and impact.
   The owner or reviewer evaluates production exposure, security and privacy impact, dependency impact, user impact, compliance relevance, and rollback complexity. NIST CM-3 calls for organizations to define configuration-controlled change types, assess proposed changes with security and privacy impacts in mind, document decisions, implement approved changes, retain records, and monitor the process (NIST SP 800-53 Rev. 5).

4. Obtain required approvals.
   Approval should match the risk tier. A low-risk standard change may use pre-approved criteria, while a high-risk production change may require security, system-owner, engineering, compliance, or change advisory review.

5. Complete testing and validation.
   Evidence may include test results, peer review, code review, staging validation, security testing, configuration checks, or acceptance sign-off.

6. Prepare failure-handling or rollback steps.
   The record should explain what the team will do if the change fails or creates a security or operational issue.

7. Schedule and communicate.
   Communicate when the change affects users, customers, support teams, security monitoring, operations, or dependent services.

8. Implement the change.
   The implementer records when the change occurred, who performed it, what was deployed or modified, and whether the implementation matched the approved request.

9. Document results.
   Record success, failure, partial completion, incidents, deviations from the plan, and links to deployment logs or configuration records.

10. Complete post-change review where needed.
    Use post-change review for emergency changes, failed changes, high-risk changes, significant production changes, or changes that caused incidents.

11. Retain evidence.
    Close the ticket only when approvals, testing, implementation records, review notes, and related evidence links are present.

Emergency changes should not bypass control entirely. They should use expedited approval, clear ownership, documented implementation, and retrospective review. Unauthorized changes should be investigated, risk-assessed, remediated where needed, and recorded as exceptions or incidents according to the organization’s process.

Approval levels and risk tiers for changes

Approval levels should basically depend on risk, not job title alone. Use this as an adaptable approval model, not a universal compliance requirement.

Low-risk or standard changes
Examples include routine, repeatable, low-impact tasks that meet pre-defined criteria. The policy may allow pre-approval if the change has a known procedure, low production risk, limited security impact, and a tested failure-handling path. Evidence should still show what was changed, when, by whom, and under what standard procedure.

Normal planned changes
These are scheduled changes with manageable risk, such as a routine application deployment, configuration update, or infrastructure adjustment. Require a documented request, risk assessment, approval by the relevant system or service owner, testing evidence, and implementation result.

Significant or high-risk changes
These may affect critical systems, sensitive data, customer-facing services, security controls, identity and access, network boundaries, or rollback complexity. Require broader review before implementation. Depending on the environment, that may include security review, engineering leadership, compliance input, business-owner approval, or a change advisory group.

Emergency changes
These are changes needed to address urgent operational, security, or availability issues. Require documented justification, expedited approval by an appropriate authority, implementation evidence, validation, and retrospective review.

Unauthorized changes
These are changes implemented without required approval or outside the approved scope. The policy should require investigation, impact assessment, remediation, and process review. NIST CM-3 enhancements address review for unauthorized changes, and NIST assessment procedures for CM-5 include change-control records and audit records as example assessment objects when evaluating change-related access restrictions (NIST SP 800-53A).

Sample change management policy wording

Adapt this wording to your systems, risk profile, operating model, and compliance obligations. It is a starting point, not a guarantee of certification.

Change request and change log field checklist

Use this as a practical editorial checklist for a ticketing tool, spreadsheet, change register, or compliance workflow. It is not a prescribed framework template.

Required fields

• Change ID.
• Requester.
• Change owner.
• Date submitted.
• Target system, service, application, or infrastructure component.
• Production or non-production environment.
• Description of the change.
• Business reason.
• Change type.
• Risk level.
• Security impact.
• Customer, user, or operational impact.
• Data or compliance impact, where relevant.
• Planned implementation date and time.
• Testing plan or validation steps.
• Failure-handling or rollback plan where material impact is possible.
• Required approvals.
• Approval date and approver.
• Implementer.
• Actual implementation date and time.
• Implementation result.
• Deviations from approved scope, if any.
• Post-change review outcome where applicable.
• Evidence links.
• Closure date.

Optional fields

• Related incident, problem, vulnerability, or service request.
• Related code review, pull request, merge request, or commit.
• Related release version or deployment package.
• Supplier involvement.
• Maintenance window.
• Communication plan.
• Monitoring plan.
• Backout decision point.
• Affected dependencies.
• Compliance framework or control mapping.
• Change advisory review notes.
• Exception reference.
• Lessons learned.

For applicable PCI DSS environments, production-system change procedures include the reason and description for the change, security-impact documentation, authorized approval, security testing, and procedures to address failures and return to a secure state. PCI DSS also calls for confirmation and documentation updates after significant changes (PCI DSS v4.0 SAQ A-EP).

Audit evidence matrix for change management

These artifacts can support audit readiness and help demonstrate that the policy operates in practice. They do not prove compliance by themselves, and not every auditor or framework requires the exact same evidence set.

SOC 2 CC8.1, NIST CM-3, NIST CM-5 assessment procedures, and PCI DSS for applicable cardholder-data environments all reinforce the same operational idea: changes should be authorized, assessed, documented, implemented in a controlled way, and supported by records close to the work.

How to keep the policy working after publication

A change management policy fails when it sits in a folder but never makes it into the workflow. Assign an owner, publish the policy where engineering, security, operations, and compliance teams can find it, and line up the required fields with the tools teams already use.

Review a sample of closed changes from time to time. Check whether approvals happened before implementation, testing evidence is present, emergency changes received retrospective review, unauthorized changes were investigated, and evidence links still work. Use exceptions and failed changes to improve the process, not just to close tickets.

Update the policy when systems, deployment methods, cloud environments, suppliers, ownership, risks, or framework obligations change. If the policy says one thing and production teams do another, fix the policy, the workflow, or both.

Ciphrix can support this operating model by helping teams connect policy clauses, control workflows, and evidence records across compliance workstreams. The main point is not the tool itself: the policy should reflect how systems actually change and how evidence is retained.