Change Management Policy Template


Company Name	[Company Name]
Effective Date	[Date]
Version	[Version Number, e.g., 1.0]
Policy Owner	[CISO/IT Director]
Document Classification	Confidential / Internal Use Only
Parent Policy	Information Security Policy

Purpose

This policy establishes a standardized and comprehensive framework for managing changes to [Company Name]'s information systems, applications, infrastructure, configurations, and processes. The purpose is to ensure that all changes are assessed, approved, implemented, and reviewed in a controlled manner to minimize disruption to services, reduce risk, maintain the security and integrity of data (including but not limited to cardholder data), ensure compliance with regulatory requirements (including PCI DSS 4.0.1), and align technology changes with business objectives.

Scope

This policy applies to all employees, contractors, consultants, temporary staff, and third-party service providers involved in proposing, assessing, approving, implementing, or reviewing changes to any part of [Company Name]'s production environments, including hardware, software, network infrastructure, security configurations (e.g., firewall rulesets), applications, databases, and related processes and documentation. This includes systems within the Cardholder Data Environment (CDE) and those that could impact the security of the CDE, as well as other critical business systems. All change types (Standard, Normal/Major, Emergency) fall under this policy.

Roles and Responsibilities

Role/Group	Key Responsibilities
Change Requester	Initiates Change Request (CR) with necessary details (justification, impact, test/rollback plans); Represents the change during review processes.
System/Application Owner	Provides technical input for CRs affecting their systems; Performs/oversees implementation; Responsible for testing and validation; Updates relevant documentation.
Change Manager	Oversees the end-to-end change management process; Facilitates Change Advisory Board (CAB) meetings; Maintains change schedule/calendar; Ensures process adherence and documentation.
Change Advisory Board (CAB)	Reviews and approves/rejects Normal/Major Change Requests based on risk, impact, and readiness; Provides guidance on change scheduling and coordination; Includes cross-functional representation (IT, Security, Business Units, Compliance).
Emergency Change Advisory Board (ECAB)	Subset of CAB or designated authorities responsible for rapid review and approval/rejection of Emergency Change Requests.
Information Security Team	Reviews changes for security impact, compliance (incl. PCI DSS), and adherence to security policies; Approves security-related changes; Participates in CAB/ECAB.
Executive Management	Provides overall oversight; Approves high-risk/high-impact changes; Ensures adequate resources for effective change management.
Business Units	Participate in defining change requirements; Perform User Acceptance Testing (UAT); Assess business impact of changes; Participate in CAB as needed.
Compliance/Audit Team	Periodically reviews change management process and records for compliance and effectiveness.

Policy Requirements

1. Change Control Procedure

1.1 Change Initiation:
- All non-standard changes must be initiated via a formal Change Request (CR) submitted through the designated Change Management system (e.g., ITSM tool).
- The CR must include, at a minimum: Detailed description, business justification, technical implementation plan, identified assets/systems affected, risk and impact assessment (including potential impact on CDE security and PCI DSS compliance), testing plan, communication plan, and a documented rollback/back-out plan (PCI DSS Req 6.4).
1.2 Change Classification:
- Changes are classified based on risk, impact, and urgency:
  - Standard Change: Low-risk, pre-approved, routine changes with established procedures (e.g., approved patch deployment via standard process). Follows a simplified workflow.
  - Normal/Major Change: Non-emergency changes requiring full assessment and CAB approval. Includes significant changes impacting critical systems, the CDE, or having potential business impact. Aligns with PCI DSS definition of "significant changes".
  - Emergency Change: Changes required immediately to restore service, fix a critical security vulnerability, or address an urgent business need. Follows an expedited process (See Section 2).
1.3 Assessment and Approval:
- All Normal/Major CRs undergo technical and security assessment to evaluate feasibility, risk, resource requirements, and potential conflicts. Security review is mandatory for changes affecting security controls or the CDE.
- The CAB reviews assessed Normal/Major CRs, considering business need, risk, impact analysis, test results (if applicable), rollback plan readiness, and scheduling. Approval requires documented CAB consensus.
- Approvals must be documented within the Change Management system.
- Separation of duties must be maintained where feasible (e.g., personnel developing code should not deploy it to production without oversight/separate approval).
1.4 Implementation and Testing:
- Approved changes are scheduled by the Change Manager, considering business impact and change windows.
- Implementers follow the approved technical plan.
- Testing must be conducted according to the test plan, verifying functionality and confirming no adverse security impact (especially on the CDE). Production data (live PANs) must not be used for testing or development. Test results must be documented.
1.5 Post-Implementation Review (PIR):
- After implementation, a PIR is conducted (formally for Major/Emergency changes) to confirm the change met objectives, assess any unforeseen impacts, and verify successful implementation.
- All related documentation (system configurations, network diagrams, inventory lists, procedures) must be updated promptly following the change. The CR remains open until documentation is confirmed updated.

2. Emergency Change Procedure

2.1 Initiation: Initiated when immediate action is required to resolve an incident, address a critical security vulnerability, or meet an urgent, unforeseen business demand.
2.2 Approval: Requires expedited review and approval from the designated ECAB members or pre-defined authorities. Verbal approval may be given to proceed but must be followed by documented approval in the Change Management system as soon as possible. Justification for the emergency classification is required.
2.3 Documentation: A CR must still be logged, potentially retrospectively, including justification, actions taken, and impact assessment. A rollback plan, even if basic, is mandatory before implementation.
2.4 Implementation: Executed immediately upon approval. Communication to stakeholders is critical.
2.5 Post-Emergency Review: All Emergency Changes undergo a formal review by the CAB at the next scheduled meeting to assess effectiveness, ensure proper documentation, identify root cause (if applicable), and determine if procedural improvements are needed.

3. Emergency Rollback Plan Procedure

3.1 Mandatory Requirement: A documented, tested (where feasible), and approved rollback plan is mandatory for all Normal/Major and Emergency changes before implementation. Standard changes rely on their pre-defined, tested procedures.
3.2 Plan Content: The plan must detail specific steps required to revert the change, dependencies, estimated time, tools needed, and clear criteria/tests to validate successful rollback.
3.3 Triggers: Rollback may be triggered by: failed post-implementation testing, unacceptable negative impact on performance or stability, introduction of security vulnerabilities, or at the direction of the Change Manager or Incident Commander if the change causes a significant incident.
3.4 Execution: Invoked by authorized personnel (Change Manager, Implementer with approval, Incident Commander). Follow the documented steps meticulously. Communicate rollback initiation to stakeholders.
3.5 Validation & Documentation: After execution, validate that the system/environment has returned to its pre-change state using the defined criteria. Document the rollback execution, reasons, outcome, and any issues encountered within the original CR.

4. Ruleset Review Procedure

4.1 Scope: Applies to the review of configurations and rulesets for security infrastructure components, including but not limited to firewalls, routers (ACLs), Intrusion Detection/Prevention Systems (IDS/IPS), Web Application Firewalls (WAF), and critical system access control lists.
4.2 Frequency:
- Firewall and router rulesets must be reviewed at least every six months (as per PCI DSS Req 1.2.4, Req 1.3.2 effective March 31, 2025, though quarterly is a common best practice).
- Other rulesets (IDS/IPS, WAF, etc.) should be reviewed at least annually or based on risk assessment frequency.
4.3 Process:
- Assign ownership for each ruleset review.
- Compare the current ruleset against documented business justifications and network/data flow diagrams.
- Identify and investigate rules lacking clear documentation or justification.
- Remove or disable obsolete, redundant, or unnecessary rules following the standard Change Management process (submit a CR).
- Verify rules enforce the principle of least privilege and align with current security policies.
- Document the review process, participants, findings, changes made (referencing CRs), and approval dates. Maintain review records for audit purposes.

5. Documentation and Records Management

All Change Requests, associated assessments, test plans/results, approvals, implementation details, PIRs, rollback plans/executions, and ruleset reviews must be documented and tracked within the designated Change Management system.
Change management records, including documentation updates, must be retained for at least one year to meet audit requirements (including PCI DSS).
The Configuration Management Database (CMDB) or relevant asset inventory must be updated as part of the change closure process.

Enforcement

Unauthorized changes or failure to adhere to this Change Management Policy may result in disciplinary action, up to and including termination of employment or contract, in accordance with established HR policies.
Systems found to have undergone unauthorized changes may be disconnected from the network until remediated.
Exceptions to this policy require written justification detailing the business need, associated risks, proposed compensating controls, and documented approval from the Change Manager and the CISO/IT Director. Approved exceptions must be documented within the relevant CR and reviewed periodically.

Revision History

Version	Date	Author	Change Details
1.0	[Date]	[Author Name]	Initial policy release
[Ver #]	[Date]	[Author Name]	[Summary of changes, e.g., Added Sec 4]

Approval

Name	Title	Signature	Date
[Exec Name]	[Executive Title, e.g., CIO]		[Date]
[CISO Name]	[CISO/IT Director Title]		[Date]

Appendix A: Change Management Process Flow (Normal/Major Change)

Initiate Change Request (CR) in System
Assess CR (Technical, Security, Risk, PCI Impact)
CAB Review & Approval?
- If Yes: Schedule Change
- If No: Reject / Request More Info (return to step 1)
Implement Change
Test Change (Functional, Security)
- If Pass: Update Documentation & CMDB
- If Fail: Invoke Rollback Plan?
  - If Yes: Execute Rollback Plan → Validate Rollback → Update Documentation & CMDB
  - If No: Troubleshoot / Remediate → Return to Testing
Post Implementation Review (PIR)
Close CR

Appendix B: Change Request Form Template - Key Fields

Change Request ID: (System Generated)
Requester: Name, Department, Contact Info
Date Submitted:
Change Title/Summary:
Detailed Description: What is being changed?
Business Justification: Why is the change needed? Benefits?
Affected Systems/Services/Applications: (Link to CMDB CIs if possible)
Priority: (e.g., Critical, High, Medium, Low)
Change Type: (Standard, Normal/Major, Emergency)
Risk Assessment: Likelihood, Impact (Technical, Business, Security)
Impact Assessment:
- Impact on users/business operations?
- Impact on system performance/availability?
- Security impact (Confidentiality, Integrity, Availability)?
- PCI DSS Impact: Does this change affect the CDE or systems impacting CDE security? If yes, specify impact on PCI DSS requirements.
Implementation Plan: Step-by-step instructions.
Testing Plan: Steps to validate success and lack of adverse effects.
Rollback Plan: Detailed steps to revert the change.
Resources Required: Personnel, hardware, software, downtime window.
Communication Plan: Who needs to be notified, when, how?
Approvals: (Workflow: Technical, Security, CAB, Business Owner)
Implementation Details: (Filled during/after implementation: Start/End Time, Implementer, Outcome)
Test Results: (Pass/Fail, Evidence Attached)
Rollback Execution: (If invoked: Reason, Outcome)
PIR Notes:
Documentation Update Confirmation: (Checkbox/Date)

Appendix C: Change Classification & Approval Matrix Example

Change Type	Risk/Impact	Description Example	Key Approvals Required	CAB Review?	ECAB Review?
Standard	Low	Approved Patch Deployment (Automated), Password Reset	Pre-Approved Procedure	No	No
Normal/Major	Low	Minor Website Content Update (Non-Critical)	Change Manager, System Owner	Optional	No
Normal/Major	Medium	Server OS Upgrade (Non-CDE), Application Feature Release	Change Manager, System Owner, Security, CAB	Yes	No
Normal/Major	High	Firewall Ruleset Change (CDE Impact), Core DB Schema Change	Change Manager, System Owner, Security, CAB, Exec Mgmt	Yes	No
Emergency	Varies	Restore service outage, Patch critical 0-day vuln	ECAB / Designated Authorities	No	Yes

Appendix D: Emergency Rollback Checklist - High Level

Confirm Trigger: Verify rollback criteria met / authorized.
Notify Stakeholders: Inform relevant parties of rollback initiation.
Access Rollback Plan: Ensure correct version of the documented plan is used.
Execute Steps: Follow the plan precisely. Document deviations if unavoidable.
Monitor Execution: Observe system behavior during rollback.
Validate Reversion: Perform tests defined in the rollback plan to confirm successful return to pre-change state.
Confirm Stability: Monitor system stability post-rollback.
Communicate Outcome: Notify stakeholders of rollback completion and status.
Document Fully: Update the CR with rollback details, reason, and outcome.
Initiate Investigation: Determine why the change failed and required rollback.

Appendix E: Ruleset Review Checklist - Example (Firewall)

Rule Documentation: Is there a documented business justification for each rule?
Rule Necessity: Is the rule still required based on current business needs and network architecture?
Rule Specificity: Is the rule appropriately specific (source/destination IPs, ports/protocols)? Avoid "Any/Any" where possible.
Least Privilege: Does the rule adhere to the principle of least privilege?
Redundancy/Shadowing: Are there redundant or shadowed rules that can be removed?
Temporary Rules: Are there temporary rules that have expired or should be removed?
Logging: Is appropriate logging enabled for significant rules (especially related to CDE)?
Alignment: Does the ruleset align with the documented network diagram and data flow diagram for CDE traffic?
Compliance: Does the ruleset configuration meet relevant PCI DSS requirements (e.g., default deny, segregation)?
Ownership: Is the owner/requester of the rule identifiable?
Last Reviewed Date: When was this specific rule/section last formally reviewed?

Appendix F: PCI DSS 4.0.1 Change Management Requirements Matrix

PCI DSS Requirement	Plan Section(s) Covering Requirement	Key Elements Addressed
Req 6.4	Policy Req 1 (Overall), Req 1.1, Req 1.3, Req 1.4, Req 1.5, Req 3.1, Req 5	Following change control processes for all system components; Includes impact analysis, documentation, approval, testing, rollback plan.
Req 6.4.1	Policy Req 1.3, Appendix F (below)	Separation of duties between development/test and production environments.
Req 6.4.2	Policy Req 1.4	Production data (live PANs) not used for testing or development.
Req 6.4.3	Policy Req 1.3, Req 1.5	Documented approval by authorized parties; Changes to custom software tested per Req 6.2.3.1.
(Implied by Req 6.4)	Policy Req 1.1, [Req 3](https://withpci.com/requirements/3	Documented impact analysis and back-out procedures required.
(Related: Req 1.2.4, Req 1.3.2	Policy Req 4	Review of firewall and router configurations at least every six months (effective 31 Mar 2025).
(Related: Req 12.3.3)	Policy Req 1.5, [Req 5](https://withpci.com/requirements/5	Documentation updated as needed when the environment changes.
(Related: Req 12.5.2)	Policy Req 3, [Req 5](https://withpci.com/requirements/5	Maintain change control history for at least one year.