Patch, Change, and Configuration Management
Key Takeaways
- Patch management applies updates to remove known vulnerabilities while controlling operational disruption.
- Change management governs the request, impact analysis, approval (CAB), testing, scheduling, backout/rollback, and stakeholder communication of any production change.
- Configuration management defines secure baselines and detects drift; standard/normal/emergency are the three change types.
- Emergency changes still require documentation, testing where feasible, and post-implementation review.
- Rollback plans, maintenance windows, and version control reduce the business impact of a failed change.
Patch, change, and configuration management are interlocking security operations processes. Patch management removes known defects; change management controls how modifications reach production; configuration management defines and maintains the approved secure state.
Change Management Process (SY0-701 named elements)
Security+ expects the formal building blocks of a change process:
| Element | Purpose |
|---|---|
| Approval process / CAB | The Change Advisory Board reviews and authorizes |
| Ownership | Named requester and owner accountable for outcome |
| Stakeholders | Everyone affected is identified and informed |
| Impact analysis | What breaks, what is the blast radius |
| Test results | Evidence the change works in staging |
| Backout / rollback plan | How to return to the prior known-good state |
| Maintenance window | Scheduled low-impact time to deploy |
| Documentation / version control | Updated diagrams, configs, and an audit trail |
Patch Management Flow
| Step | Example |
|---|---|
| Identify update | Vendor releases a security update for a web framework |
| Assess applicability | Determine which apps use the affected version |
| Prioritize | Raise priority for internet-facing or sensitive systems |
| Test | Apply in staging, run smoke tests |
| Approve | Business and technical owners approve the window |
| Deploy | Patch in a maintenance window or via emergency process |
| Verify | Confirm version, service health, and rescan status |
| Document | Record systems patched, exceptions, and failures |
Patching balances security urgency against availability: delaying a critical, exploited patch exposes the business, but pushing an untested patch to a fragile system can cause its own outage. Real environments stage patches in rings — a small pilot group first, then broader waves — so a bad update is caught before it reaches the whole fleet. Many vendors release on a predictable cadence (Microsoft's monthly Patch Tuesday is the classic example), which lets teams pre-schedule maintenance windows, while out-of-band releases for actively exploited flaws break that cadence and trigger the emergency path.
After deployment, agentless and agent-based reporting must confirm the patch actually applied; a patch reported as 'deployed' by the management console but absent on a rebooted-during-install endpoint is exactly the kind of silent gap attackers find.
The Three Change Types
| Type | Description | Example |
|---|---|---|
| Standard | Preapproved, low-risk, repeatable | Monthly workstation patch deployment |
| Normal | Requires CAB review and approval | Upgrade a production database cluster |
| Emergency | Urgent change to cut immediate risk or restore service | Firewall rule to block active exploitation |
Emergency does not mean undocumented: review is accelerated, but approvals, implementation notes, and a post-implementation review still occur. The exam loves to test this exact misconception with a distractor that lets an administrator make an urgent fix with no record 'because there was no time.' That is wrong — the change advisory board may convene a fast quorum or grant pre-delegated emergency authority, but the change is still logged, tested where feasible, and reviewed afterward so the organization understands what was altered and why.
Version control underpins the whole process. Approved baselines, infrastructure-as-code, firewall rule sets, and golden images live in a versioned repository so every change has an author, a timestamp, a diff, and a rollback target. When a change goes wrong, you revert to the prior commit; when an auditor asks who changed a firewall rule, the history answers. Treating change records as disposable paperwork defeats both of those benefits.
Configuration Baselines and Drift
A secure baseline (often hardened to CIS Benchmarks or DISA STIGs) defines the approved state: password policy, logging, encryption, disabled services, firewall rules, and audit options. Configuration drift is any deviation from that baseline.
| Baseline item | Drift example | Risk |
|---|---|---|
| Full-disk encryption enabled | Disabled for troubleshooting | Lost device exposes data |
| Endpoint logging enabled | Agent stopped or removed | Reduced detection/investigation |
| SSH root login disabled | Re-enabled for convenience | Brute-force and accountability risk |
| TLS 1.2+ required | Legacy protocol re-enabled | Weak-encryption exposure |
Worked Decision Example
A vendor patches a critical flaw in a business-critical, internet-facing payment app handling confidential data. Staging shows the patch breaks one optional reporting screen but core payments work.
| Issue | Decision |
|---|---|
| Security urgency | High — exposed and sensitive |
| Business impact | Core payment still functional |
| Change type | Emergency or expedited normal |
| Compensating control | Increase monitoring; restrict suspicious requests |
| Backout | Stage prior package and a database backup |
| Follow-up | Fix the reporting screen after the risk-reducing patch ships |
Common Traps
- Applying patches with no rollback plan on critical systems.
- Treating change control as paperwork instead of risk management.
- Letting emergency changes bypass all records.
- Fixing software versions while leaving insecure drift in place.
- Failing to verify that patches actually reached the target systems.
Exam Focus
For SY0-701, pick answers that combine risk reduction with controlled implementation: test, approve, schedule, deploy, verify, document, and prepare a backout plan. Emergency change is correct for urgent exploited issues — but it still needs evidence and review.
A critical internet-facing system needs an urgent security patch outside the normal monthly window. Which change type best fits?
During change planning, what is the purpose of a backout (rollback) plan?
What is configuration drift?
Which items belong in a sound patch deployment process? Select three.
Select all that apply