What Is Vulnerability management? Security Definition

Imagine you own a house with many doors and windows. Some doors might have weak locks, some windows might not close properly, and maybe there is a hidden entrance you forgot about. If a burglar finds one of these weak spots, they could get inside and steal your valuables.

Vulnerability management is like having a security guard who walks around your house every week checking every door, every window, every lock, and every possible entry point. When the guard finds a problem, such as a broken lock, they note it down and decide how urgently it needs to be fixed. A broken lock on the back door is a big problem because it lets anyone in, so that gets fixed right away.

A small crack in a window on the second floor might be less urgent because it is harder to reach, but it still gets scheduled for repair. The guard also keeps a list of all known weak spots from other houses in the neighborhood and checks if your house has the same issues. Over time, the guard comes back every week because new problems can appear.

Perhaps a lock gets rusty, or a new type of burglar tool is invented that can open a certain kind of lock. The guard updates the checklist and keeps working. In the IT world, vulnerability management works exactly the same way.

Computer systems, networks, and applications all have weaknesses. Some are known publicly, like a software bug that allows an attacker to take control. Others are discovered by security researchers or even by attackers themselves.

A vulnerability management program uses special tools to scan all the computers, servers, and devices on a network, looking for these known weaknesses. It then creates a report that lists every vulnerability found, along with a severity score. The most critical vulnerabilities, such as one that allows remote code execution without a password, are fixed immediately.

Less critical ones, like a minor information disclosure, might be scheduled for the next maintenance window. The key idea is that this is not a one-time thing. New vulnerabilities are announced every day, sometimes by the software vendors themselves.

So the scanning and fixing must happen continuously. That is why vulnerability management is called a cycle. It goes around and around: identify, analyze, remediate, and repeat. This constant attention helps organizations stay ahead of attackers who are always looking for the next open door.

Vulnerability management is a structured, cyclical process that encompasses the identification, classification, prioritization, remediation, and verification of security vulnerabilities across an organization's information technology assets. It is a foundational component of an enterprise security program and is prescribed by numerous frameworks, including NIST SP 800-40, ISO 27001, and the CIS Controls. The process is typically implemented using a combination of automated scanning tools, manual assessment techniques, and a formalized policy that defines frequency, scope, and response procedures.

The vulnerability management lifecycle consists of several distinct phases. The first phase is asset discovery and inventory. Before any scanning can occur, an organization must have a complete and accurate inventory of all devices, servers, applications, and network components. Without this, scanning may miss critical systems, leaving them unprotected. Asset discovery tools use active scanning, passive listening, and integration with configuration management databases (CMDB) or cloud provider APIs to build this inventory. This phase often includes identifying the operating system, version, installed applications, open ports, and running services for each asset.

The second phase is vulnerability scanning. Automated scanners, such as Nessus, Qualys, OpenVAS, or Microsoft Defender Vulnerability Management, probe each asset for known vulnerabilities. These scanners reference databases of Common Vulnerabilities and Exposures (CVEs) maintained by the MITRE Corporation. Each CVE is assigned a severity score using the Common Vulnerability Scoring System (CVSS), which considers factors like attack vector, attack complexity, privileges required, user interaction, and impact on confidentiality, integrity, and availability. Scans can be authenticated or unauthenticated. Authenticated scans use credentials to log into the system and perform a deeper inspection of configuration settings, missing patches, and registry values, yielding more accurate results. Unauthenticated scans operate from the network side and may detect fewer issues but provide an attacker's perspective.

The third phase is analysis and prioritization. Raw scan results often contain hundreds or thousands of vulnerabilities, many of which may be low risk or false positives. Security analysts must triage the findings. This involves validating each vulnerability, correlating it with the organization's risk appetite, considering the criticality of the affected asset (e.g., a public-facing web server vs. an internal development workstation), and factoring in the presence of compensating controls such as firewalls or intrusion prevention systems. Vulnerability prioritization is often guided by the CVSS score, but many organizations also incorporate threat intelligence feeds that indicate which vulnerabilities are currently being exploited in the wild. This allows teams to focus on zero-day vulnerabilities or actively exploited flaws first, rather than simply patching in order of CVSS severity.

The fourth phase is remediation. Remediation strategies include applying patches or updates from the vendor, implementing configuration changes, applying workarounds such as disabling a vulnerable service, or deploying virtual patches via a web application firewall (WAF) or intrusion prevention system (IPS). For vulnerabilities that cannot be immediately patched due to operational constraints, formal risk acceptance or a mitigation plan must be documented and approved by management. Remediation is typically tracked through a ticketing system, with assigned owners and target completion dates based on severity. Typical SLA targets for critical vulnerabilities range from 24 hours to 7 days, while low-severity issues may have 90 days or longer.

The fifth phase is verification and reporting. After remediation actions have been applied, the organization rescan the affected assets to confirm that the vulnerability has been successfully eliminated. This step also includes generating reports for stakeholders, such as IT management, compliance officers, and auditors. Reports typically show metrics like mean time to remediate (MTTR), patch compliance percentage, vulnerability trends over time, and risk score improvement. These reports are essential for demonstrating due diligence to regulators and for justifying additional security investments.

The final phase is continuous improvement. Vulnerability management is not a point-in-time activity. The cycle repeats on a defined schedule, which may be weekly, monthly, or quarterly depending on the organization's risk profile and regulatory requirements. Continuous improvement involves refining scanning configurations, updating asset inventories, integrating new threat intelligence sources, and adjusting prioritization criteria based on lessons learned from past incidents.

From a technical implementation perspective, vulnerability management relies on several standards and protocols. The Security Content Automation Protocol (SCAP) is used to automate the exchange of vulnerability data between scanners and management platforms. SCAP includes the Common Platform Enumeration (CPE) for naming software, the Common Configuration Enumeration (CCE) for configuration issues, and the Open Vulnerability and Assessment Language (OVAL) for describing checks. The Extensible Configuration Checklist Description Format (XCCDF) is used for benchmark checklists.

In cloud environments such as AWS and Azure, vulnerability management includes scanning of virtual machine images in the cloud, container images, serverless functions, and Infrastructure as Code (IaC) templates. Cloud-native tools like Amazon Inspector and Microsoft Defender for Cloud provide integrated vulnerability scanning that aligns with the shared responsibility model. For on-premises environments, vulnerability scanners are often deployed as virtual appliances within the network, and agents may be installed on endpoints that leave the corporate network, such as laptops.

Vulnerability management is distinct from vulnerability assessment, which is a point-in-time evaluation, and from penetration testing, which is a goal-oriented attack simulation. Vulnerability management is the ongoing operational process that ensures the organization's security posture is continually maintained and improved.

Vulnerability management matters because it is the primary proactive defense against cyberattacks. Most data breaches and ransomware incidents are caused by attackers exploiting known vulnerabilities that the organization had not patched. According to industry reports, over 90% of successful cyberattacks exploit vulnerabilities that have a known patch available. This means that if a company had simply applied the available patches, the attack would have failed. Vulnerability management directly reduces this attack surface by systematically identifying and fixing those weaknesses before an attacker finds them.

For IT professionals, vulnerability management is not optional. Regulatory frameworks like PCI DSS, HIPAA, and GDPR require organizations to implement a vulnerability management program. Auditors will ask for scan reports, remediation records, and proof that the process is ongoing. Failure to have a proper program can result in fines, loss of certification, or legal liability. Vulnerability management helps prioritize security spending. With thousands of potential vulnerabilities to address, you need a data-driven way to decide which ones to fix first. Vulnerability management provides that prioritization, ensuring that the most dangerous issues get attention immediately.

From a career perspective, understanding vulnerability management is essential for roles such as security analyst, security engineer, SOC operator, and compliance officer. It is a core skill that appears in many certification exams, including Security+, CySA+, CISSP, and cloud-specific certifications like AWS SAA and Azure AZ-104. Knowing how to design, implement, and report on a vulnerability management program demonstrates a mature understanding of risk management and operational security.

Exam questions about vulnerability management typically fall into three categories: scenario-based, configuration-based, and troubleshooting-based.

Scenario-based questions present a real-world situation and ask you to decide the best course of action. For example: A security analyst receives a vulnerability scan report showing a critical remote code execution vulnerability on a public-facing web server. The server cannot be patched immediately because the application vendor has not yet released a fix. What should the analyst do next? The correct answer might be to implement a virtual patch using a web application firewall while awaiting the vendor patch. Other options might include taking the server offline, which is too disruptive, or ignoring the vulnerability, which is unacceptable. These questions test your understanding of compensating controls and risk management.

Configuration-based questions ask about the tools and settings involved in vulnerability scanning. For instance: An administrator wants to perform a vulnerability scan on a set of servers to get the most accurate results. Which type of scan should be used? The answer is an authenticated scan because it has credentials and can check for missing patches and configuration issues that an unauthenticated scan would miss. Or: Which protocol is used to automate the exchange of vulnerability data between a scanner and a management platform? The answer is SCAP (Security Content Automation Protocol).

Troubleshooting-based questions focus on why a vulnerability might not have been detected or why a remediation failed. For example: After applying a critical security patch, a system still appears in the vulnerability scan report as vulnerable. What could be the cause? Possible answers include: the system was not rebooted after patching, the patch was not installed correctly, the vulnerability is actually a different but similar CVE that was not patched, or the scan was using an outdated plugin database. Another troubleshooting scenario: A vulnerability scanner reports a critical vulnerability on a server, but a manual review shows the server does not have the affected software. This is a false positive. The correct action is to mark the finding as a false positive and adjust the scanner configuration to exclude it in future scans.

Multiple-choice questions also test your knowledge of the vulnerability management lifecycle stages. You might be asked: Which phase of the vulnerability management process involves ranking vulnerabilities based on their criticality and the asset value? The answer is the prioritization phase. Or: What is the final step in the vulnerability management cycle after remediation has been applied? The answer is verification scanning or rescanning to confirm the vulnerability is fixed.

Some questions integrate vulnerability management with broader incident response. For instance: During a security incident, the incident response team finds evidence that an attacker used a known vulnerability on an unpatched server. What should the organization do after the incident? The best answer is to treat the root cause as a gap in the vulnerability management program and improve the scanning and patching schedule for similar assets. This tests your ability to see vulnerability management not just as a tool but as a process that feeds into continuous improvement.

In practice, vulnerability management is not just about running a scanner and applying patches. It requires coordination across many teams, a clear policy, and a culture that accepts that security is everyone's responsibility. As a security professional, you will likely be the person who runs the scans, but you will also need to communicate findings to system administrators who may be overloaded with other work. You must learn to present risk in business terms so that managers understand why a critical vulnerability needs immediate attention even if it means delaying a feature release.

One common challenge is handling vulnerabilities on legacy systems that cannot be patched because the vendor no longer supports them, or because the application running on them requires a specific operating system version. In such cases, you cannot simply apply the patch, so you must implement compensating controls. These might include isolating the system on a separate network segment, placing it behind a firewall with strict access control lists, deploying an intrusion prevention system that blocks exploit attempts, or using application whitelisting to prevent unauthorized executables. Every compensating control must be documented and its effectiveness tested regularly.

Another practical aspect is the integration of vulnerability management with configuration management and change management. When a vulnerability is found due to a configuration error, such as an open SMB port that should be closed, the fix is not a patch but a configuration change. That change must go through the change management process to ensure it does not break connectivity or applications. Configuration drift can occur after a system is initially hardened, so regular scanning helps detect when settings revert to insecure defaults.

From an architectural perspective, large organizations often deploy vulnerability scanners in a distributed fashion. A management console centralizes policies and results, while remote scanners are placed in different network segments to reduce firewall congestion. Firewall rules must allow scanner traffic to all target systems on the necessary ports. For cloud environments, agent-based scanning is often preferred because it does not require opening inbound ports. Agents are installed on virtual machines and send scan results to the cloud provider's management platform.

A critical success factor is obtaining the right credentials for authenticated scans. Windows systems need domain accounts with appropriate privileges, Linux systems need root or sudo access, and database servers need database credentials. Storing these credentials securely is a challenge; many scanners integrate with privileged access management solutions to retrieve credentials on demand rather than storing them permanently.

Finally, vulnerability management programs must adapt to the speed of modern development. DevOps and agile practices mean new code is deployed multiple times per day. Traditional weekly or monthly scanning may not catch vulnerabilities introduced between scans. This has led to the rise of continuous vulnerability management, where scanning is integrated into CI/CD pipelines. Containers are scanned at build time, and running containers are scanned periodically. Infrastructure as Code (IaC) templates are analyzed for misconfigurations before deployment. This shift left approach catches vulnerabilities earlier, reducing remediation cost and effort.

The vulnerability management lifecycle is the structured, continuous process that organizations use to identify, classify, prioritize, remediate, and mitigate vulnerabilities in their systems and applications. This lifecycle is central to many security certifications, including the CompTIA Security+, CySA+, ISC2 CISSP, and AWS SAA. Understanding each phase in depth is critical for exam success and real-world implementation.

The first phase is discovery and inventory. Before any vulnerability can be managed, an organization must have a complete and accurate inventory of all assets, including hardware, software, cloud instances, and network devices. This phase involves asset discovery tools, configuration management databases (CMDB), and cloud inventory services like AWS Config or Azure Resource Graph. Without a full asset inventory, vulnerability scans will miss critical systems, leaving gaps in the security posture. Exam questions often test whether candidates understand that asset discovery must precede scanning.

The second phase is vulnerability scanning and assessment. This involves using tools like Nessus, Qualys, OpenVAS, or cloud-native solutions such as Amazon Inspector or Microsoft Defender for Cloud to scan systems for known vulnerabilities. Scans can be authenticated or unauthenticated, internal or external, and can target specific operating systems, applications, or network protocols. It is crucial to understand the difference between credential-based (authenticated) scans, which provide deeper insight, and unauthenticated scans, which simulate an external attacker's view. In exams, you may be asked to choose the appropriate scan type based on a scenario.

The third phase is prioritization and risk scoring. Not all vulnerabilities pose the same level of risk. Frameworks like CVSS (Common Vulnerability Scoring System) provide a base score, but real-world risk also depends on asset criticality, exploit availability, and threat intelligence. For example, a CVSS 9.0 vulnerability on an internet-facing web server might be prioritized higher than a CVSS 10.0 vulnerability on an isolated internal printer. The CySA+ and CISSP exams emphasize the need to combine CVSS with business context. Prioritization techniques include using the EPSS (Exploit Prediction Scoring System) and integrating threat feeds.

The fourth phase is remediation and mitigation. Remediation involves applying patches, updating software, or reconfiguring systems to eliminate the vulnerability. Mitigation is used when a patch is not immediately available, and may involve compensating controls such as firewall rules, intrusion prevention signatures, or disabling vulnerable services. It is important to distinguish between remediation (fixing the root cause) and mitigation (reducing risk without fixing). In incident response and vulnerability management workflows, SLAs are often defined for critical vulnerabilities, and automated patch management tools like WSUS or AWS Systems Manager Patch Manager are used.

The fifth phase is verification and reporting. After remediation, a rescan is performed to confirm that the vulnerability has been successfully addressed. Reports are generated for stakeholders, including technical teams, management, and auditors. These reports often include metrics such as mean time to remediate (MTTR), vulnerability density, and risk score trends. For the Security+ and MS-102 exams, understanding how to interpret vulnerability scan results and generate meaningful reports is a key objective.

The final phase is continuous improvement. Vulnerability management is not a one-time project; it is a cyclical process. Lessons learned from past incidents, scan results, and threat intelligence are used to refine the scanning schedule, update asset inventories, and improve prioritization criteria. This aligns with the Deming cycle (Plan-Do-Check-Act) often referenced in CISSP and ISO 27001 contexts.

the vulnerability management lifecycle provides a structured approach to reduce organizational risk. Exam questions frequently test the order of phases, the purpose of each step, and the tools associated with them. Candidates who master this lifecycle will be well-prepared for both exams and their careers.

A critical distinction in vulnerability management is between authenticated and unauthenticated scans. Both scan types serve different purposes and provide different levels of insight. Understanding when to use each is a frequent objective in exams like Security+, CySA+, and AZ-104. This section explains the technical differences, use cases, and exam scenarios.

An unauthenticated scan, also known as an external scan, does not provide any credentials to the target system. The scanner attempts to discover vulnerabilities by probing open ports, analyzing banners, and attempting to interact with services from a remote perspective. This simulates what an external attacker would see without any privileged access. Unauthenticated scans are faster, require less configuration, and are often used for external perimeter assessments or internet-facing systems. However, they are limited because they cannot access file systems, registry settings, or configuration details that require authentication. Many vulnerabilities, especially those related to missing patches or misconfigured registry keys, are only detectable via authenticated scans. In exams, you may be presented with a scenario where an unauthenticated scan missed critical vulnerabilities, and you need to recommend authenticated scanning.

An authenticated scan, or credential-based scan, uses valid user credentials (often domain administrator or local administrator) to log into the target system. This allows the scanner to perform a deep inspection of the operating system, installed software, registry, file permissions, and configuration settings. For example, an authenticated scan can check whether a specific security update is installed by querying the Windows Update history or by checking file versions directly. It can also detect vulnerabilities in service accounts, weak local passwords, or insecure registry keys that would be invisible to an unauthenticated scan. However, authenticated scans require careful management of credentials, increased network traffic, and potentially elevated privileges that must be stored securely. In cloud environments, such as AWS, authenticated scans of EC2 instances require the Systems Manager agent and appropriate IAM roles. The AZ-104 exam may ask about using Azure Update Management or Microsoft Defender for Cloud with credential-based scanning.

When choosing between the two, consider the scope and objectives. For a comprehensive internal vulnerability assessment, authenticated scans are strongly recommended because they reduce false negatives and provide a more accurate picture of the security posture. For external penetration tests or firewall audits, unauthenticated scans may suffice. In SIEM and SOAR workflows, both scan results are often ingested and correlated to prioritize findings.

Exam trick: Questions often describe a scenario where an organization only runs unauthenticated scans and discovers that many vulnerabilities are not being detected. The correct answer is usually to implement authenticated scanning with appropriate credentials and least-privilege permissions. Another trick is to recognize that authenticated scans require network access to the target, so if a system is isolated or has host-based firewalls blocking the scanner, authenticated scans may fail. Understanding these nuances is critical for passing vulnerability management questions.

authenticated scans provide depth, while unauthenticated scans provide breadth from an external attacker's perspective. The best vulnerability management programs use both in combination, with authenticated scans running monthly or weekly and unauthenticated scans running continuously for external assets. This dual approach ensures comprehensive coverage and is a theme across multiple certification domains.

CVSS, or the Common Vulnerability Scoring System, is the industry standard for assigning a numerical score to vulnerabilities based on their severity. However, on its own, CVSS is insufficient for effective prioritization in a real-world vulnerability management program. Exams such as the CISSP, CySA+, and Security+ test not only the mechanics of CVSS scoring but also its limitations and how to combine it with other factors.

CVSS version 3.1 scores vulnerabilities from 0.0 to 10.0, with 10.0 being the most severe. The base score is calculated from three metric groups: the Base metrics (exploitability and impact), Temporal metrics (current exploit status and patch availability), and Environmental metrics (specific to the organization's environment). The Base metrics are the most commonly cited, and include Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI), Scope (S), Confidentiality (C), Integrity (I), and Availability (A). For example, a vulnerability with AV:N (network), AC:L (low), PR:N (none), UI:N (none) and high impact on all CIA triad components would receive a high base score, possibly 9.0 or 10.0.

While CVSS provides a standardized severity rating, exam questions often highlight its weaknesses. First, CVSS does not account for the specific business context. A CVSS 7.5 vulnerability on an internet-facing web server handling payment data is far more critical than a CVSS 9.0 vulnerability on a printer used only internally. Second, CVSS does not consider exploit maturity. A vulnerability that has a documented proof-of-concept exploit and is being actively used in the wild should be prioritized much higher than one that is only theoretical. Third, CVSS does not factor in the value of the affected asset. High-value servers, domain controllers, and databases should receive higher priority regardless of CVSS score.

To address these limitations, modern vulnerability management programs use risk-based vulnerability management (RBVM) frameworks. RBVM combines CVSS with threat intelligence feeds (e.g., CISA KEV, Exploit-DB), asset criticality ratings (tier 1, tier 2, etc.), and exposure factors (e.g., internet-facing vs. internal). The result is a prioritized list that answers the question, Which vulnerabilities should we fix first? Tools like Qualys VMDR, Tenable.io, and Rapid7 InsightVM incorporate these techniques. In the CISSP exam, you may be asked to describe how to create a risk-based prioritization policy that aligns with business objectives.

EPSS (Exploit Prediction Scoring System) is becoming increasingly important. EPSS uses machine learning to predict the likelihood that a vulnerability will be exploited in the next 30 days. A vulnerability with a high EPSS score (e.g., >0.9) indicates a high probability of exploitation and should be remediated urgently, even if its CVSS score is moderate. The CySA+ exam may include questions about using EPSS alongside CVSS.

In practice, a common prioritization workflow is: first, filter for vulnerabilities that have known exploits (CISA KEV or EPSS >0.5). Second, apply asset criticality – assign higher priority to systems that handle sensitive data or are critical to business operations. Third, consider the network exposure – internet-facing systems are higher risk. Fourth, use CVSS score to fine-tune within that subset. This multi-step approach is more effective than relying solely on CVSS.

Exam clue: A question may present a list of vulnerabilities with CVSS scores and ask which should be patched first. The correct answer is not always the highest CVSS score; it is the one that combines a high CVSS score with a known exploit and a critical asset. Understanding that CVSS is just one input in a broader decision-making process is key.

mastering CVSS and its integration with other prioritization factors is essential for vulnerability management professionals. The ability to articulate why a CVSS 7.5 vulnerability might be more urgent than a CVSS 10.0 vulnerability is exactly the kind of analytical thinking that exams and real-world roles require.

Once vulnerabilities have been identified and prioritized, organizations must decide how to respond. The three primary strategies are remediation, mitigation, and acceptance. Each has its own place in a vulnerability management program, and exam questions from Security+ through CISSP frequently test the differences and appropriate applications.

Remediation means completely eliminating the vulnerability. The most common form of remediation is applying a software patch or security update. For example, if a critical vulnerability exists in a Windows Server version, installing the latest cumulative update from Microsoft would be remediation. Remediation can also involve upgrading the software to a newer, non-vulnerable version, or replacing the hardware entirely. In cloud environments, remediation might mean updating an Amazon Machine Image (AMI) or redeploying an Azure VM with the latest configuration. From an exam perspective, remediation is always the preferred option when feasible because it removes the root cause. However, it may not be immediately possible due to operational constraints, compatibility issues, or scheduled maintenance windows.

Mitigation refers to reducing the risk of a vulnerability without actually fixing the underlying flaw. This is often used when a patch is unavailable or cannot be applied quickly. Common mitigation measures include applying a firewall rule to block the vulnerable port, implementing an intrusion prevention system (IPS) signature to block exploit traffic, disabling vulnerable services or features, or using network segmentation to isolate the vulnerable system. For example, if a vulnerability exists in the RDP service, mitigation could involve disabling RDP or restricting access to specific IP addresses. Another example is enabling Data Execution Prevention (DEP) or Address Space Layout Randomization (ASLR) to make exploitation more difficult. Mitigation is temporary and should be followed by full remediation as soon as possible. In the CISSP exam, you will be asked to identify appropriate compensating controls when a patch cannot be applied.

Acceptance is a risk management decision where the organization acknowledges the vulnerability but decides not to take any action. This is only valid when the risk is deemed low or the cost of remediation exceeds the potential impact. Acceptance must be formally documented, typically through a risk acceptance form signed by an authorized manager or risk owner. The vulnerability management team should track accepted risks and periodically review them to see if conditions have changed (e.g., a new exploit is released). In regulated environments, acceptance may be limited or require additional approvals. The CySA+ exam may present a scenario where an administrator must decide whether to accept a risk based on business impact.

A fourth, less common strategy is remediation through configuration change. Sometimes a vulnerability is not caused by missing patches but by misconfiguration. For example, a server with default credentials, open permissions, or unnecessary services running. Fixing these is a form of remediation that does not involve patching. Hardening baselines like CIS Benchmarks or Microsoft Security Baselines are excellent references for such fixes.

Important exam concepts: SLA-driven remediation – many organizations have Service Level Agreements that dictate how quickly vulnerabilities must be fixed based on severity. For example, critical vulnerabilities must be patched within 24 hours, high within 72 hours, and medium within 30 days. Also, understanding patch management cycles – not all patches can be deployed immediately due to testing requirements. In the MS-102 exam, you might manage update rings for Windows 10/11 devices using Windows Update for Business, ensuring patches are tested in a pilot group before broad deployment.

Finally, verification after remediation is crucial. A rescan must confirm that the vulnerability no longer exists. False positives can occur if a patch was applied incorrectly or the scanner misidentified the issue. The vulnerability management team should have a process for marking findings as fixed only after successful verification.

the choice between remediation, mitigation, and acceptance depends on factors like patch availability, operational impact, and risk appetite. Security professionals must be able to recommend the most appropriate strategy based on a given scenario, and exams will test this decision-making ability thoroughly.