Patch, Change, and Configuration Management
Key Takeaways
- Patch management applies updates to reduce known vulnerabilities while controlling operational disruption.
- Change management evaluates risk, approval, testing, scheduling, rollback, and communication.
- Configuration management maintains approved secure states and detects drift from baselines.
- Emergency changes still need documentation, testing where feasible, and post-implementation review.
- Rollback plans and maintenance windows reduce the business impact of failed changes.
Patch, Change, and Configuration Management
Patch management, change management, and configuration management are connected security operations processes. Patching removes known defects. Change management controls how modifications reach production. Configuration management defines and maintains the approved secure state.
Patch Management Flow
| Step | Example |
|---|---|
| Identify update | Vendor releases security update for web framework |
| Assess applicability | Determine which applications use the affected version |
| Prioritize | Raise priority for internet-facing or sensitive systems |
| Test | Apply in staging and run smoke tests |
| Approve change | Business and technical owners approve window |
| Deploy | Patch during maintenance window or emergency process |
| Verify | Confirm version, service health, and vulnerability scan status |
| Document | Record systems patched, exceptions, failures, and next actions |
Patch management must balance security urgency against availability. Delaying a critical exploited patch can expose the organization. Deploying a poorly tested patch to a fragile production system can also harm the business.
Change Types
| Change type | Description | Example |
|---|---|---|
| Standard | Preapproved, low-risk, repeatable | Monthly workstation patch deployment |
| Normal | Requires review and approval | Upgrade database version on production cluster |
| Emergency | Urgent change to reduce immediate risk or restore service | Apply firewall rule to block active exploitation |
Emergency does not mean undocumented. It means the review is accelerated, with appropriate approvals, implementation notes, and post-change review.
Configuration Baselines and Drift
A secure baseline is an approved configuration state. It may define password policy, logging settings, encryption requirements, disabled services, firewall rules, endpoint protection, and audit options. Configuration drift occurs when a system moves away from the approved state.
| Baseline item | Drift example | Risk |
|---|---|---|
| Full disk encryption enabled | Encryption disabled for troubleshooting | Lost device could expose data |
| Endpoint logging enabled | Agent stopped or removed | Reduced detection and investigation capability |
| SSH root login disabled | Root login enabled for convenience | Increased brute-force and accountability risk |
| TLS 1.2 or newer required | Legacy protocol reenabled | Weak encryption exposure |
Worked Decision Example
A vendor releases a patch for a critical flaw in a payment application. The application is business-critical, internet-facing through an API gateway, and processes confidential customer data. Testing shows the patch breaks one optional reporting screen but core payment flow works.
Reasonable decision:
| Issue | Decision |
|---|---|
| Security urgency | High because the application is exposed and sensitive |
| Business impact | Core payment remains functional |
| Change type | Emergency or expedited normal change |
| Compensating controls | Increase monitoring and restrict suspicious request patterns |
| Rollback | Prepare prior package and database backup plan |
| Follow-up | Fix reporting screen after risk-reducing patch is deployed |
The organization should not ignore the broken reporting screen, but the security and business context support rapid patching with documented residual issues.
Operational Decision Rules
| Situation | Best operational response |
|---|---|
| Critical patch fails testing | Use compensating controls, document exception, continue remediation planning |
| Emergency fix deployed | Complete post-implementation review and update records |
| Baseline drift detected | Investigate whether change was approved, then remediate or document exception |
| Unsupported system cannot be patched | Isolate, monitor, replace, or formally accept risk with owner approval |
| Patch window missed repeatedly | Escalate aging risk and ownership, not just reschedule silently |
Common Traps
- Applying patches without a rollback plan for critical systems.
- Treating change control as paperwork instead of risk management.
- Allowing emergency changes to bypass all records.
- Fixing software versions while leaving insecure configuration drift in place.
- Failing to verify that deployed patches actually reached the target systems.
Exam Focus
For SY0-701, choose answers that combine risk reduction with controlled implementation: test, approve, schedule, deploy, verify, document, and prepare rollback. For urgent exploited issues, emergency change may be correct, but it still needs evidence and review.
A critical internet-facing system needs an urgent security patch, but the change must happen outside the normal monthly window. Which change type best fits?
What is configuration drift?
Which items belong in a sound patch deployment process? Select three.
Select all that apply