SECURITY CHANGE MANAGEMENT PROCEDURE

Change Security Review · Emergency Changes · Control Impact · SOX ITGC Linkage

Table of Contents

1. Purpose and Scope
2. Principles
3. What Is a Security-Relevant Change
4. Change Categories
5. Security Review Requirements
6. Emergency Changes
7. SOX and Regulated-Scope Changes
8. Evidence and Records
9. Metrics
10. Roles and Responsibilities
11. Regulatory and Framework Alignment Summary
12. Document Control

1. Purpose and Scope

CERG does not replace the enterprise change management process. It supplies the security review discipline that process needs. A change can be operationally approved and still be a bad security change if it weakens a baseline, creates a new trust boundary, bypasses logging, changes privileged access, affects SOX scope, or pushes unresolved risk into production.

This procedure defines how security-relevant changes are identified, reviewed, evidenced, escalated, and linked to risk acceptance or architecture review. It also defines the minimum security handling for emergency changes and for changes affecting SOX ITGC, CUI, NERC-CIP, and other regulated scope.

Change Management Is Where Controls Stay True

A baseline is not defeated all at once. It erodes one exception, one rushed firewall rule, one emergency admin grant, one disabled log source at a time. Security change management is the discipline that catches that erosion while it is still a change request, not a finding six months later.

2. Principles

1. CERG reviews security impact, not business priority. The business decides whether a change is important. CERG decides whether the change weakens, bypasses, or requires controls.
2. Security review is proportional. A minor baseline-preserving change does not need a full architecture review. A material change to identity, network, data, cloud, OT, or regulated scope does.
3. Emergency does not mean undocumented. Emergency changes may move faster, but they still record what changed, why, who approved it, and how it was reviewed afterward.
4. Changes with residual risk use the risk process. A change that introduces unresolved security risk is not waved through informally. It is remediated or accepted through CERG-PRC-RM-001.
5. SOX scope gets evidence discipline. Financially relevant systems require stronger change evidence: request, approval, testing, implementation, and segregation of duties.

3. What Is a Security-Relevant Change

A change is security-relevant if it creates, removes, weakens, bypasses, or materially alters a security control, trust boundary, privileged access path, sensitive data path, or regulated system.

Security-relevant changes include:

• network segmentation, firewall, routing, remote access, VPN, or proxy changes;
• identity provider, MFA, SSO, privileged access, service account, or federation changes;
• cloud landing zone, account, subscription, tenant, storage, or policy changes;
• endpoint, EDR, MDM, logging, backup, or cryptography control changes;
• changes to applications that process Confidential or Restricted data;
• changes to SOX, CUI, NERC-CIP, OT, or safety-impacting environments;
• new third-party data exchange or vendor integration;
• emergency control bypasses;
• new AI capability or AI-enabled feature touching business data;
• changes that resolve or introduce a risk-register item.

A change not on this list may still be security-relevant if the Engineering Pillar Leader, Risk Pillar Leader, or Governance Pillar Leader determines that it affects control posture.

3.1 Materiality

The term “material” is used throughout this procedure and related CERG documents to distinguish changes that fundamentally alter security posture from those that are routine. A change is “material” if it meets any of the following criteria:

• Affects systems in SOX, CUI, or NERC-CIP regulated scope
• Modifies trust boundaries or network segmentation between environments
• Introduces new external connectivity (internet-facing services, vendor interconnects, API gateways)
• Changes identity or privilege models (federation, PAM topology, role-based access architecture)
• Introduces a new data classification into an environment
• Impacts more than 100 users or a customer-facing production service
• Introduces a new SaaS platform, cloud account, or cloud service

A change is explicitly NOT material if it:

• Is a routine patch or version upgrade within the same product line
• Reuses a pre-approved architecture pattern without modification
• Adds capacity to an already-reviewed system without changing its architecture
• Is a configuration change within the DISH-conformant baseline
• Is a standard user provisioning or de-provisioning action

When classification is ambiguous, the Engineering Pillar Leader determines materiality in consultation with the relevant pillar leader for the affected scope.

4. Change Categories

4.1 Security Review Workflow

The following workflow defines the step-by-step process from change submission through security review to closure.

Decision Points Summary

Change Submitted
    │
    ├── Not security-relevant ──► No CERG review
    │
    └── Security-relevant
            │
            ├── Standard (sampled) ──► Sample review or no review
            ├── Emergency ──► Emergency approval + post-review
            └── Normal / Material / Control Bypass
                    │
                    ├── Approved ──► Implement + Evidence
                    ├── Approved with Conditions ──► Conditions met → Implement + Evidence
                    ├── Requires Architecture Review ──► PRC-AR-001
                    ├── Requires Risk Acceptance ──► PRC-RM-001
                    └── Rejected ──► Return to requester

4.2 Sampling Methodology for Standard Changes

Standard security-preserving changes do not require individual CERG review, but a sample is reviewed each month to verify that the “standard” classification is accurate and that security posture is not degrading through accumulated small changes.

5. Security Review Requirements

5.1 Minimum Review Questions

Every normal security-relevant change answers these questions before implementation:

1. What system, control, data path, or trust boundary changes?
2. What data classification is affected?
3. Does the change affect identity, privilege, logging, encryption, backup, segmentation, endpoint posture, or vendor access?
4. Does the change affect SOX, CUI, NERC-CIP, OT, or other regulated scope?
5. Does the change create a new threat model trigger under CERG-PRC-TM-001?
6. Does the change create residual risk, and if so, is that risk recorded and approved?
7. What evidence will prove the change was approved, tested, implemented, and verified?
8. What rollback or recovery plan exists?

5.2 Review Outcomes

A change cannot be closed as security-approved until conditions, risk acceptances, or architecture-review actions are linked.

5.3 Security Review SLAs

Security reviews are time-bound to prevent the review process from becoming a bottleneck. The following SLAs apply from the time a complete change request is received.

SLA Escalation

5.4 Integration with Enterprise Change Management

CERG does not replace the enterprise change management process. This section defines how the two processes interface.

Interface Workflow

Handoff Responsibility

• The Engineering Pillar Leader is responsible for ensuring CERG review outcomes are communicated back to the enterprise change management system.
• The Change Manager in the enterprise CM process is responsible for enforcing CERG outcomes: a change rejected by CERG must not proceed through the enterprise change process unless the rejection is overturned or the change is modified and re-reviewed.

Conflict Resolution

If the enterprise change management process and CERG disagree on a change’s security disposition:

6. Emergency Changes

Emergency changes are allowed, but they are not a loophole.

6.1 Emergency Criteria

A change may be treated as emergency only when delay creates unacceptable operational, security, safety, or compliance impact. Convenience is not an emergency.

6.2 Minimum Emergency Record

The emergency change record contains:

• business or operational reason for emergency treatment;
• systems and controls affected;
• approver;
• implementer;
• start and completion time;
• change performed;
• testing or validation performed;
• rollback result or reason rollback was not needed;
• post-implementation security review outcome.

6.3 Post-Implementation Review

Emergency changes receive post-implementation security review within the organization’s defined emergency-change window, and no later than the next business review cycle. The review confirms that:

1. the emergency criteria were valid;
2. the change is documented;
3. no unintended control bypass remains;
4. required evidence is retained;
5. any residual risk is recorded;
6. any temporary access, firewall rule, control disablement, or exception is removed or formally accepted.

Emergency Is a Speed, Not a Standard

An emergency change moves faster because the situation requires speed. It does not get a lower evidence bar, a lower approval bar, or a free pass on residual risk. The evidence may be completed after implementation, but it still exists. The review may occur after the change, but it still occurs. Emergency is the route, not the destination.

7. SOX and Regulated-Scope Changes

Changes affecting SOX ITGC, CUI, NERC-CIP, OT, or other regulated environments require additional evidence and review.

7.1 SOX ITGC

For SOX-scope systems, the change record must show:

• request and business justification;
• approval before implementation, except valid emergency changes;
• evidence of testing;
• implementer and approver;
• segregation of duties or compensating control where the same person requests, approves, tests, or implements;
• implementation evidence;
• post-implementation validation;
• link to the relevant SOX ITGC control in CERG-PLN-SOX-001.

7.2 CUI, NERC-CIP, and OT

For CUI, NERC-CIP, and OT-scope systems, the change record must show the regulatory scope considered, the relevant compliance manager consulted, and any required evidence retained in the evidence library under CERG-PRC-AUD-001.

8. Evidence and Records

Security change records are evidence. They are retained under CERG-PRC-AUD-001 and include, at minimum:

9. Metrics

10. Roles and Responsibilities

Roles below are canonical role names from CERG-GOV-OM-001 §6.1.

11. Regulatory and Framework Alignment Summary

12. Document Control

Revision History

Review Triggers

• Material change to enterprise change management
• Material change to SOX scope or ITGC expectations
• Repeated emergency-change findings
• Significant incident or audit finding caused by a change
• Direction from the CISO

Cyber Engineering owns this document. The Engineering Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes.

Related Documents

Source: procedures/CERG-PRC-CHG-001_Security_Change_Management_Procedure.md · Download .md · View on GitHub