Security Operations · Topic 3 of 9
Configuration, Change and Patch Management
Configuration management with baselines and automation, the change management process and CAB, and patch and vulnerability management in operations.
- 3 min
- Baselines define the approved state; automation enforces it and detects drift.
- Change process: request, impact analysis, approval, test, implement, document.
- Standard, normal and emergency changes.
What it is
Three related processes keep systems in a known, approved, secure state. Configuration management defines and enforces baselines. Change management controls how systems are altered. Patch and vulnerability management fixes known weaknesses quickly without breaking production.
How it works
Configuration management
| Element | Meaning |
|---|---|
| Provisioning | Building systems from approved images or templates |
| Baselining | Recording the approved configuration |
| Automation | Infrastructure as code and configuration tools apply and enforce settings |
| Drift detection | Comparing running systems with the baseline and alerting on unapproved differences |
| Configuration audit | Confirming deployed systems match the approved baseline |
Manual steps get skipped under pressure. Automated, scheduled collection of configurations with alerts on unapproved differences catches drift even when engineers forget to update records.
Change management process
- Request: describe the change, reason and rollback plan.
- Impact analysis: including security and continuity impact.
- Approval: by a change advisory board (CAB) or delegated authority.
- Test: in an environment that matches production baselines.
- Implement: in an agreed window.
- Document and review: update records, baselines and plans.
| Change type | Handling |
|---|---|
| Standard | Pre-approved, low-risk, repeatable |
| Normal | Full review and approval |
| Emergency | Expedited approval, documented and reviewed afterwards |
When a pre-approved standard change is being used for high-risk actions (for example adding users to domain administrators), exclude the high-risk cases from the standard change rather than slowing every request.
Security's role in change
Security should assess changes with security impact before implementation. If a change with security impact was approved without security review, request a security impact assessment before it goes live, and make sure future changes include a security and continuity check before closure.
Patch management
| Step | Detail |
|---|---|
| Inventory | Know every system and software version |
| Identify | Monitor vendor releases and vulnerability feeds |
| Prioritize | By severity, exploitation in the wild and asset criticality |
| Test | In staging that matches production, especially for business-critical apps |
| Deploy | In stages, with rollback plans |
| Verify | Confirm installation and rescan |
Vulnerability management
Scan regularly, rate findings (for example with CVSS) in business context, assign owners and due dates, track remediation, and handle exceptions formally. For systems that cannot be patched, isolate them and add compensating controls.
How the exam asks about this
- "A change passed in staging but failed in production because of different settings." Keep staging aligned to production baselines.
- "The router was restored from a 14-month-old configuration." Pull configurations automatically and alert on unapproved differences.
- "A vendor patch once broke a custom reporting app." Test it against that app in staging first.
What to remember for the exam
- Baselines define the approved state; automation enforces it and detects drift.
- Change process: request, impact analysis, approval, test, implement, document.
- Standard, normal and emergency changes.
- Patch: inventory, identify, prioritize, test, deploy, verify.
- Security and continuity impact belong in change review.
Emergency changes still need documentation and after-the-fact review. Skipping that turns emergencies into a back door around change control.
Common mistakes
Testing in environments that differ from production.
Relying on people to update configuration backups manually.
Blocking all changes instead of targeting the risky ones.
Check yourself
What is configuration drift?
Differences between running systems and their approved baseline.
What should happen to an emergency change after implementation?
It should be documented and reviewed through the change process.
Why test patches in staging?
To find conflicts with business applications before they affect production.
Topic 3 of 9 in Security Operations
Test yourself on Security Operations
The full ISC2 CISSP question bank has 1,113 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISC2. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.