Patch, Change, and Configuration Management

CompTIA Security+ SY0-701

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook

2 Domain 1: General Security Concepts (12%)

CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact

3 Domain 1: Identity, Trust, and Cryptography Basics

AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules

4 Domain 2: Threat Actors, Vectors, and Social Engineering

Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios

5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks

Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping

6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities

Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions

7 Domain 3: Security Architecture - Secure Architecture Models

Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios

8 Domain 3: Security Architecture - Network Security Architecture

Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design

9 Domain 3 Part C: Data Protection and Resilience

Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience

10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT

Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security

11 IAM Operations and Access Control

Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring

12 Logging, Monitoring, and Detection

Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling

13 Incident Response

IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics

14 Digital Forensics and Investigation

Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps

15 Vulnerability, Patch, Asset, and Automation Operations

Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling

16 Governance, Policies, and Risk Management

Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting

17 Third-Party Risk, Compliance, and Privacy

Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences

18 Audits, Penetration Testing, and Awareness

Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls

19 Final Review and PBQ Labs

PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation

Patch, Change, and Configuration Management

Key Takeaways Explain This Topic AI

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.

Last updated: June 2026

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.