Security+ 1.3 — Explain the importance of change management processes and the impact to security.

Status: done

Exam objective

Explain the importance of change management processes and the impact to security.

Official CompTIA scope (SY0-701 v5.0)

Open PDF on page 5


My notes

What is Change Management?

Definition: Systematic approach to handling organizational changes to implement them smoothly and successfully with minimal disruption.

Goal: Control changes to IT systems while maintaining security and minimizing risk.

Why It Matters for Security:


Business Processes Impacting Security Operations

1. Approval Process

Definition: Formal authorization required before implementing changes

Key Principle: NEVER make changes without approval

Approval Workflow:

Change Request → Impact Analysis → CAB Review → Approval/Denial → Implementation
Change Advisory Board (CAB)
Levels of Approval

Exam Tip: “Approval process” questions — CAB is almost always involved for normal changes


2. Ownership

Definition: Clear assignment of WHO is responsible for the change

Change Owner/Initiator
Change Implementer
System/Asset Owner

Why Ownership Matters:

Exam Scenario: “Who should approve a firewall change?” — System owner (firewall admin) + Security team


3. Stakeholders

Definition: Anyone affected by or who can affect the change

Common Stakeholders:

Stakeholder Involvement:

Exam Tip: Questions about “who should be involved” — Think broader than just IT!


4. Impact Analysis

Definition: Assessing potential effects of a change before implementation

Security Impact
Business Impact
Technical Impact
Risk Analysis

Impact Assessment Questions:

  1. What could go wrong?
  2. How likely is failure?
  3. How bad would failure be?
  4. Can we recover quickly?
  5. Do benefits outweigh risks?

Exam Keyword: “Impact analysis” = Assessing consequences BEFORE implementing


5. Test Results

Definition: Evidence that change works as expected in test environment

Pre-Implementation Testing
Test Environment

Documentation Required:

Exam Trap: Changes should NEVER go to production without testing first!


6. Backout Plan

Also called: Rollback plan, remediation plan

Definition: Procedure to reverse a change if it causes problems

Why Critical:

Rollback Procedure
  1. Trigger criteria (when to roll back)
  2. Step-by-step reversal process
  3. Who performs rollback
  4. Time required to roll back
Backups
Recovery Point

Exam Scenario: “Change causes system crash. What should be done first?” — Execute backout plan to restore service

Best Practice: Test the backout plan too!


7. Maintenance Window

Definition: Scheduled time period when changes can be made with minimal business impact

Purpose:

Timing
Duration
Communication

Types:

Exam Tip: “When should changes be made?” — During maintenance windows!


8. Standard Operating Procedure (SOP)

Definition: Documented step-by-step instructions for implementing changes

Purpose:

SOP Contents:

Examples of Change SOPs:


Technical Implications

1. Allow Lists / Deny Lists

Impact: Changes can affect what’s permitted/blocked

Allow Lists (Whitelists)
Deny Lists (Blacklists)

Change Management Considerations:

Exam Scenario: “Adding IP to firewall allow list” — Changes who can access (security impact!)


2. Restricted Activities

Definition: Actions that are limited or prohibited during certain times

Why Restrict:

Change Freeze
Restricted Times
Approval Escalation

Exam Keyword: “Change freeze” = Absolutely NO changes during this period


3. Downtime

Definition: Period when system is unavailable due to change

Types:

Planned Downtime
Unplanned Downtime

Minimizing Downtime:

SLA Considerations:

Exam Tip: Changes SHOULD be planned for maintenance windows to minimize downtime


4. Service/Application Restart

What It Is: Stopping and starting services as part of change

Why Required:

Restart Sequence
Service State
User Impact

Best Practices:

Exam Scenario: “After firewall config change…” — Typically requires restart to apply!


5. Legacy Applications

Definition: Older applications still in use but outdated

Can’t Be Changed
Can’t Be Patched
Security Implications

Change Management for Legacy Apps:

Workarounds:

Testing:

Exam Scenario: “Can’t patch legacy system…” — Use compensating controls (network segmentation, monitoring)


6. Dependencies

Definition: Systems, applications, or services that rely on each other

Why Critical for Change Management:

Technical Dependencies
Operational Dependencies

Dependency Mapping:

Change Impact on Dependencies:

Change database schema
  ↓
Application queries fail
  ↓
Web portal down
  ↓
Users can't log in

Exam Tip: Always consider dependencies in impact analysis!


Documentation

1. Updating Diagrams

Why Important: Visual representations must match reality

Types of Diagrams to Update:

Network Diagrams
Data Flow Diagrams
Architecture Diagrams

When to Update:

Consequences of Outdated Diagrams:


2. Updating Policies/Procedures

Security Policies
Procedures
Configuration Standards

Documentation Requirements:

Exam Scenario: “After implementing new firewall…” — Update firewall management procedures and network diagram!


3. Version Control

Definition: Tracking changes to configurations and code over time

Configuration Files
Code and Scripts

Version Control Benefits:

Version Control Systems:

Best Practices:

Exam Tip: Version control provides audit trail and enables quick rollback


Change Management Workflow

Complete Process:

1. IDENTIFY NEED FOR CHANGE
   ↓
2. CREATE CHANGE REQUEST
   - Document what, why, who, when
   - Include stakeholders
   ↓
3. CONDUCT IMPACT ANALYSIS
   - Security, business, technical impacts
   - Risk assessment
   ↓
4. DEVELOP IMPLEMENTATION PLAN
   - Step-by-step procedure
   - Resource requirements
   - Timeline
   ↓
5. CREATE BACKOUT PLAN
   - Rollback procedures
   - Recovery steps
   ↓
6. CAB REVIEW & APPROVAL
   - Present to Change Advisory Board
   - Answer questions
   - Get approval
   ↓
7. SCHEDULE MAINTENANCE WINDOW
   - Coordinate timing
   - Notify stakeholders
   ↓
8. TEST IN NON-PRODUCTION
   - Validate change works
   - Document test results
   ↓
9. IMPLEMENT CHANGE
   - Follow SOP
   - Monitor during implementation
   ↓
10. VERIFY & TEST
    - Confirm change successful
    - Test dependent systems
    ↓
11. UPDATE DOCUMENTATION
    - Diagrams, policies, procedures
    - Version control
    - Close change request
    ↓
12. POST-IMPLEMENTATION REVIEW
    - Lessons learned
    - Document any issues
    - Update procedures if needed

Common Change Management Failures

Failure: Skipping Approval

Failure: No Testing

Failure: No Backout Plan

Failure: Poor Communication

Failure: Ignoring Dependencies

Failure: Outdated Documentation


Memory Aids

Change Management Steps: “I-CREATE-VERIFY”

Critical Change Documents: “BAT PITs”

Technical Impacts: “DARLA”


Common Exam Traps

Trap 1: “Emergency = No Approval Needed”

Trap 2: “Small Change = No Testing”

Trap 3: “Update Docs Later”

Trap 4: “Backout Plan = Nice to Have”

Trap 5: Legacy Apps Can’t Be Secured


Exam tips

  1. Change management is about CONTROL — Preventing unauthorized, untested, or poorly planned changes
  2. CAB approves, change owner implements — Know the roles
  3. Testing is NOT optional — All changes must be tested first
  4. Backout plan is mandatory — Must exist before approval
  5. Documentation must be updated immediately — Not “later”
  6. Maintenance windows minimize impact — Schedule changes appropriately
  7. Legacy apps need compensating controls — Can’t patch does not equal can’t secure
  8. Dependencies matter — One change can break multiple systems
  9. Emergency changes still need approval — Just expedited process
  10. Version control provides audit trail — Track all configuration changes

Pro Tip: When you see “change management” in a question, think about the PROCESS and APPROVAL, not just the technical change itself.


Key terms


Examples / scenarios

Scenario 1: A database administrator wants to apply a critical security patch to the production database server immediately. The patch was just released.

Scenario 2: During a change implementation, the new firewall rules cause the company’s VPN to stop working.

Scenario 3: A company has a legacy billing application that hasn’t been updated in 10 years. The vendor no longer supports it.


Mini quiz

Question 1: Which of the following BEST describes the purpose of a Change Advisory Board (CAB)? **Answer: To review and approve/deny change requests based on risk and impact** The CAB's primary function is governance — they review change requests, assess risks and impacts, and make approval decisions. They don't implement changes (that's the change implementer's job), create backout plans (change owner does this), or update documentation (various roles do this).
Question 2: What TWO things should be completed BEFORE a firewall rule change is approved? (Impact analysis and backout plan) **Answer: Impact analysis and backout plan** BEFORE approval, you need: - **Impact analysis**: Understand what could go wrong - **Backout plan**: How to recover if it fails - **Test results**: Proof it works (also before approval) AFTER approval: Stakeholder notification, implementation, documentation updates, post-implementation review.
Question 3: A company implements a new application firewall rule but forgets to update the network diagram. Three months later, this causes a failed audit. Which change management component was neglected? **Answer: Documentation** The network diagram is documentation that must be updated when changes are made. Failing to update it violates the documentation requirement of change management. Best Practice: Update documentation IMMEDIATELY after change, not "later."
Question 4: Which of the following is the MAIN reason for testing changes in a non-production environment first? **Answer: To identify and fix issues before affecting production** The PRIMARY purpose of testing is to find problems in a safe environment where they won't impact users or business operations. If the change breaks something, it's better to discover it in test/dev than in production!
Question 5: A legacy medical records system cannot be patched because updates break critical functionality. What should the security team do? **Answer: Implement compensating controls such as network segmentation** When primary controls (patching) can't be used, implement compensating controls: network segmentation (isolate), enhanced monitoring, strict access controls, dedicated firewall rules. Breaking critical functionality or decommissioning may not be feasible.

CompTIA-style practice questions

Question 6: A security engineer is planning to update firewall rules during a maintenance window. Which of the following should be completed BEFORE the change is approved? (Choose TWO)
A. Post-implementation review
B. Impact analysis
C. Backout plan
D. Documentation updates
E. Stakeholder notification
**Correct Answers: B. Impact analysis and C. Backout plan** BEFORE approval, you need: - **Impact analysis**: Understand what could go wrong - **Backout plan**: How to recover if it fails AFTER approval: - Stakeholder notification (before implementation) - Implementation - Documentation updates - Post-implementation review **Timeline matters in change management questions!**
Question 7: Which of the following BEST describes the purpose of a maintenance window?
A. To prevent all system changes indefinitely
B. To schedule changes during a period of minimal business impact
C. To test changes in a production environment
D. To eliminate the need for a backout plan
**Correct Answer: B. To schedule changes during a period of minimal business impact** Maintenance windows are scheduled time periods for implementing changes with minimal disruption. They don't replace testing or backout plans.
Question 8: A legacy medical records system cannot be patched because updates break critical functionality. The system is required for regulatory compliance. What should the security team do?
A. Patch the system anyway and fix the functionality later
B. Decommission the system and migrate to a new platform
C. Implement compensating controls such as network segmentation
D. Request an exception from the regulatory body
**Correct Answer: C. Implement compensating controls such as network segmentation** When primary controls (patching) can't be used, implement compensating controls: - Network segmentation (isolate) - Enhanced monitoring - Strict access controls - Dedicated firewall rules **Why not the others?** - A: Breaking critical functionality is not acceptable - B: May not be feasible (time, cost, complexity) - D: Regulatory exceptions are rare and don't fix security issues


Domain 1: General Security Concepts

Objective Title Status
1.1 Compare and contrast various types of security controls done
1.2 Summarize fundamental security concepts done
1.3 Explain the importance of change management processes (current) done
1.4 Explain the importance of using appropriate cryptographic solutions done
← Previous: Objective 1.2 Back to Dashboard Next: Objective 1.4 →