Change Management and the Incident Response Plan

Why This Topic Matters
Software does not stay secure on its own. Every patch, feature, configuration tweak, or emergency fix is a chance to introduce a vulnerability, and every security incident is a test of whether the organization can detect, contain, and learn from failure. The CSSLP places Change Management and the Incident Response Plan (IRP) inside the Secure Software Lifecycle Management domain because both are operational controls that preserve the security posture established during design and development. Uncontrolled change is one of the most common root causes of outages and breaches; an absent or untested incident response plan turns a manageable event into a crisis. Together these two disciplines close the loop of the secure lifecycle: incidents reveal weaknesses, and controlled change fixes them without creating new ones.

Part 1: What Is Change Management?
Change management is the formal, documented process used to request, evaluate, approve, implement, verify, and record modifications to software, infrastructure, and configurations. Its goals are to:
• Prevent unauthorized or undocumented changes.
• Assess the security and operational impact of each change before it is made.
• Ensure changes are tested and reversible (rollback plan).
• Maintain the integrity of baselines and traceability from request to deployment.

Change management is closely related to but distinct from configuration management. Configuration management identifies and controls configuration items (CIs) and baselines; change management governs how those items are allowed to change. Version control systems, build pipelines, and release management tooling support both.

How Change Management Works
A typical change process follows these steps:
1. Request for Change (RFC): The initiator documents what will change, why, scope, affected systems, and urgency.
2. Impact and Risk Analysis: Security, operations, and development evaluate the security impact, dependencies, performance effects, and regulatory implications. This is where threat model updates and security regression considerations belong.
3. Approval: A Change Advisory Board (CAB) or designated change authority approves, defers, or rejects the change. Separation of duties requires that the person requesting or building a change is not the sole approver.
4. Testing: The change is validated in a non-production environment, including security testing (regression tests, vulnerability scans, code review as appropriate).
5. Implementation: The change is deployed during an approved window with a documented back-out or rollback plan.
6. Verification and Closure: Post-implementation review confirms the change achieved its objective without side effects; the configuration baseline and documentation are updated and the RFC is closed.

Types of Changes
• Standard change: Low-risk, pre-approved, repeatable (for example, routine certificate rotation using an approved procedure).
• Normal change: Requires full assessment and CAB approval.
• Emergency change: Must be implemented quickly to resolve an outage or active security incident. It uses an expedited approval path (often an Emergency CAB) but must still be documented and retroactively reviewed. The exam frequently tests that emergency changes do not bypass documentation.

Security Considerations in Change Management
• Patch management is a specialized form of change management; security patches need prioritization based on exploitability and exposure, but still require testing and rollback planning.
• Separation of duties between development, testing, and production deployment prevents a single individual from inserting malicious or untested code.
• Audit trails of changes support forensics, compliance, and accountability.
• Unauthorized changes detected in production (configuration drift) are themselves security events and should be investigated.

Part 2: What Is the Incident Response Plan?
An incident response plan is the documented, approved set of policies, procedures, roles, and communication protocols that an organization follows when a security event becomes a security incident. A security event is any observable occurrence; a security incident is an event that actually or potentially violates security policy or compromises confidentiality, integrity, or availability. For software professionals, incidents include exploited vulnerabilities, data breaches through application flaws, malicious code in the supply chain, credential compromise, and denial of service against the application.

The IRP exists so that decisions are made calmly in advance rather than improvised under pressure. It defines what constitutes an incident, who is on the Computer Security Incident Response Team (CSIRT), how severity is classified, who must be notified (internally, regulators, customers, law enforcement), and how evidence is preserved.

How Incident Response Works (NIST SP 800-61 Lifecycle)
The CSSLP aligns with the NIST SP 800-61 model, which has four phases:
1. Preparation: Build the IRP, train the team, establish logging and monitoring, define escalation paths and communication templates, secure out-of-band communications, and ensure tools (forensic kits, secure storage, contact lists) are ready. From a software perspective this includes designing applications to produce useful, tamper-evident logs and having a coordinated vulnerability disclosure process.
2. Detection and Analysis: Identify indicators from logs, intrusion detection, user reports, or external disclosure. Triage to confirm the incident, determine scope, classify severity, and begin documentation. Accurate time synchronization and centralized logging are critical.
3. Containment, Eradication, and Recovery: Containment limits damage (short-term such as isolating a host; long-term such as applying a temporary workaround). Eradication removes the root cause (remove malware, close the vulnerability, revoke compromised credentials). Recovery restores systems to normal operation and monitors for recurrence. Fixes applied here are emergency changes and must flow through the expedited change process.
4. Post-Incident Activity (Lessons Learned): Conduct a blameless review, perform root cause analysis, update the IRP, feed findings back into requirements, threat models, secure coding standards, and test cases so the same class of flaw is prevented in future releases.

Key Incident Response Concepts
• Evidence handling and chain of custody: Preserve volatile data first, create forensic images, document who handled what and when, so evidence remains admissible.
• Communication plan: Pre-defined internal and external messaging; legal and public relations involvement; regulatory breach-notification timelines (such as those under GDPR or sector-specific laws).
• Severity classification: Drives response speed, escalation, and resources.
• Testing the plan: Tabletop exercises, simulations, and full drills validate that the IRP actually works and that people know their roles.
• Relationship to BCP/DRP: Incident response handles the security event; business continuity and disaster recovery handle sustaining and restoring operations when the incident causes significant disruption.

Part 3: How Change Management and Incident Response Interact
• Incidents often trigger emergency changes; the IRP should reference the emergency change procedure so fixes are rapid but controlled and documented.
• Poorly managed changes are a leading cause of incidents, so change records are a primary investigative source during Detection and Analysis.
• Post-incident root cause analysis produces normal changes (permanent fixes, hardening, new controls) that go through the standard process.
• Both rely on accurate configuration baselines: you cannot detect unauthorized change or assess incident scope without knowing the known-good state.
• Both require metrics: change success rate, number of emergency changes, mean time to detect, mean time to contain, and mean time to recover indicate the maturity of lifecycle management.

Exam Tips: Answering Questions on Change Management and the Incident Response Plan
1. Process first, heroics second. When a scenario describes a developer or administrator fixing something directly in production without approval, the correct answer almost always identifies this as a failure of change management, even if the fix worked.
2. Emergency does not mean undocumented. If an option says an emergency change can skip documentation or review, it is wrong. The correct answer is expedited approval with retroactive review and documentation.
3. Know the order of change steps. Request, impact analysis, approval, test, implement with rollback plan, verify, update baseline. Questions may ask what comes before approval (impact analysis) or what is missing (rollback plan, post-implementation review).
4. Separation of duties is a favorite. The person who writes the code should not be the one who approves and deploys it to production.
5. Memorize the NIST SP 800-61 phases and be able to place an action in the correct phase. Isolating a server is containment; removing malware is eradication; restoring from clean backup is recovery; updating the plan is post-incident activity; training and logging configuration are preparation.
6. Distinguish event from incident. An event is any observable occurrence; an incident violates or threatens security policy. Not every alert is an incident.
7. Preserve evidence before you fix. If the question involves forensics or potential legal action, the best first action usually protects volatile data and chain of custody rather than immediately rebuilding the system.
8. Lessons learned feed the SDLC. When asked how incident response contributes to secure software, the answer is that root cause analysis updates requirements, threat models, coding standards, and test cases to prevent recurrence.
9. The most important preparation step is often the plan itself and testing it. If a scenario shows confusion during an incident, the root cause is typically an untested or non-existent IRP, not a lack of tools.
10. Look for the stakeholder keywords. Legal, public relations, regulators, and executive management belong in the communication plan; developers and operations belong on the CAB and in technical containment. Match the role to the responsibility.
11. Read for the word BEST or FIRST. CSSLP questions often offer several reasonable actions; choose the one that reflects formal process, risk assessment, and documentation over speed or convenience unless the question explicitly describes an active, ongoing attack requiring immediate containment.
12. Patch management is change management. A question about applying a critical vendor patch is still asking whether you tested it, planned rollback, and documented it, even if the timeline is compressed.

Summary
Change management protects the integrity of software after release by ensuring every modification is assessed, approved, tested, reversible, and recorded. The incident response plan ensures the organization can detect, contain, eradicate, recover from, and learn from security incidents in a predictable, evidence-preserving way. On the exam, favor answers that emphasize formal process, documented approval, separation of duties, the NIST incident lifecycle, evidence preservation, and feeding lessons learned back into the secure software lifecycle.