CompTIA SY0-701: Vulnerability Management & Patch Management — Study Guide

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Part of the CompTIA Security+ SY0-701 — Complete Study Guide. Practice with verified answers in the CompTIA exam hub, or take timed practice tests on ExamRoll.io.

Vulnerability management is the continuous process of identifying, classifying, remediating, and verifying security weaknesses across an organization’s technology estate. It is not a project with an end date but an operational discipline that must keep pace with a threat landscape that produces hundreds of new CVEs every week.

The Vulnerability Management Lifecycle

The lifecycle begins with asset discovery — you cannot protect what you do not know exists. Active scanning (Nessus, Qualys, Rapid7) probes the network for live hosts and open services. Passive discovery (network traffic analysis, DHCP logs, CMDB integration) catches assets that active scans miss. Cloud environments require API-based discovery because traditional network scanning does not enumerate serverless functions, managed services, or ephemeral containers.

Scanning follows discovery. Authenticated scans provide complete visibility into installed software, patch levels, and configuration weaknesses. Unauthenticated scans are useful for external attack surface assessment but miss the majority of vulnerabilities. Scan frequency should match risk: internet-facing assets weekly, internal servers monthly, workstations monthly with continuous agent-based monitoring.

Prioritization uses CVSS as the baseline but must incorporate context. A CVSS 9.8 vulnerability on an air-gapped development server is less urgent than a CVSS 7.5 vulnerability on a public-facing authentication endpoint. EPSS scores, KEV catalog membership, asset criticality, and compensating controls all adjust the effective priority. The goal is not to patch everything — it is to patch the right things first.

Remediation options include patching (preferred), configuration change (disabling a vulnerable feature), virtual patching (WAF rule blocking exploitation), network isolation, or formal acceptance with documented rationale. Remediation SLAs must be defined and tracked; exceptions require approval and a compensating control.

Verification confirms that remediation was effective. A rescan after patching confirms the vulnerability is no longer present. Verification is often skipped under time pressure, leading to situations where a patch was deployed but not applied correctly, or where the vulnerability was remediated on one instance but not others in the same tier.

Patch Management Operations

Patch management operationalizes the remediation phase. A mature program includes a patch testing pipeline: patches are applied first to a non-production environment, validated for compatibility and functionality, then promoted to production through a change management process. Emergency patches for actively exploited vulnerabilities may bypass the full testing cycle with expedited change approval.

Windows Server Update Services (WSUS) and Microsoft Endpoint Configuration Manager (MECM/SCCM) are common tools for managing Windows patches at scale. Linux environments use package managers (apt, yum, dnf) combined with automation tools (Ansible, Puppet, Chef) to enforce patch state. Cloud-native environments use AWS Systems Manager Patch Manager, Azure Update Management, or equivalent services.

Patch compliance reporting tracks the percentage of assets within SLA for each severity tier. A dashboard showing 94% compliance for critical patches sounds acceptable until you realize that 6% of 10,000 endpoints is 600 unpatched systems — each a potential entry point. Absolute numbers matter as much as percentages.

Configuration Management and Baselines

Configuration management maintains systems in a known, secure state. Configuration baselines define the approved state for each system type; drift detection identifies deviations from that baseline. Tools like CIS-CAT Pro, OpenSCAP, and cloud-native services (AWS Config, Azure Policy) continuously assess configuration compliance and alert on drift.

Change management governs modifications to production systems. Every change should have a documented rationale, risk assessment, rollback plan, and approval from appropriate stakeholders. Emergency changes — required outside the normal change window — follow an expedited process with post-implementation review. Unauthorized changes detected by configuration management tools are treated as security events until proven otherwise.

Practical Scenario: Log4Shell Response Under Pressure

When CVE-2021-44228 (Log4Shell) was disclosed on December 9, 2021, with a CVSS score of 10.0 and active exploitation within hours of disclosure, organizations faced a crisis that tested every aspect of their vulnerability management programs. A technology company with a mature program responded as follows: within two hours, the security team queried their asset inventory for all Java applications and identified 847 potentially affected systems. Within six hours, they had confirmed 312 systems running vulnerable Log4j versions through authenticated scanning. Within 24 hours, they had deployed WAF rules blocking the ${jndi: string pattern as a temporary compensating control across all internet-facing systems. Within 72 hours, 89% of critical systems were patched. The remaining 11% were isolated on restricted network segments pending application owner approval for patching windows. The program’s success depended on three prerequisites that many organizations lacked: a complete, accurate asset inventory; authenticated scanning capability; and pre-approved emergency change procedures that could be invoked without a week-long approval cycle.

← Endpoint · All domains

Practice these questions → · Timed practice on ExamRoll.io →